PCI Compliance Deadline: You have until June 30 to Disable TLS 1.0
Disable TLS 1.0 or prepare for hefty penalties
Do you have an e-commerce website? Do you accept online payments? Do you worry about getting penalized for PCI non-compliance? If the answer to all three questions is ‘Yes,’ then you should disable TLS 1.0 right away. The time for thinking about it has passed. You only have a few more days!
The Payment Card Industry Security Standards Council (PCI SSC) is an independent body formed by American Express, Discover Financial Services, JCB International, MasterCard and Visa Inc. in 2006. This body was established to protect cardholders’ data, and it has specified twelve primary requirements for all vendors that accept online payments. While these requirements are not part of any laws, they payment card companies have made it mandatory for merchants that accept card payments. If a merchant fails to be compliant, they can face monthly fines up to $100,000.
PCI DSS v3.1, published in April 2015 had a deadline of June 2016 for migrating from SSL and early TLS to the newer, more secure versions. Here, “migrating from SSL and early TLS” means disabling support for older SSL & TLS versions. Eventually, this deadline was extended by two years and June 30, 2018 was made the new deadline.
PCI DSS v3.2, published in April 2016 also included this deadline.
Why is this happening?
As we grow older, we start losing our powers. Security protocols are no different. Secure Socket Layer (SSL), the original cryptographic protocol had its last version (SSL 3.0) released in 1999. Due to the vulnerabilities found in the SSL versions, SSL was soon replaced by TLS. Since then, four versions of TLS have been published with TLS 1.0 dating back to 1999.
The early versions of SSL and TLS have been found susceptible to vulnerabilities such as Heartbleed, POODLE, BEAST, CRIME, and Bleichenbacher—this includes TLS 1.0. Such a window of opportunity invites hackers to intercept and tamper with customers’ sensitive credit card data— a man-in-the-middle attack in technical terms.
Granted, it’s not as easy as I’m making it sound, but it’s certainly a possibility—especially when it comes to e-commerce and online payments with obvious and lucrative incentives involved.
What needs to be done
Now you might be wondering why we don’t just ban said protocols. Well, as good as it sounds, it’s not practical. There is no central authority that can disable older SSL/TLS versions for the entire internet; it has to be done on servers by server admins.
Many sites are still run on old servers that don’t support the latest TLS versions. For example, Windows Server 2008 doesn’t support TLS 1.1, 1.2 and 1.3. Admins of such sites need to act ASAP and migrate to newer servers. Even if you have migrated to a newer server or already have one, you’re not done. You also need to disable support for SSL/early TLS.
Which SSL/TLS versions should be disabled?
This is what the document from the PCI SSC says about SSL/TLS versions to be disabled:
“POIs can continue using SSL/early TLS when it can be shown that the POI is not susceptible to the currently known exploits. However, SSL is an outdated technology and may be subject to additional security vulnerabilities in the future; it is therefore strongly recommended that POI environments use TLS v1.1 or greater wherever possible. New implementations of POIs should strongly consider support for and use of TLS 1.2 or greater. If SSL/early TLS is not needed in the environment, use of and fallback to these versions should be disabled.”
To put it in simple words, you need to disable TLS 1.0 and all SSL versions. It is also highly recommended that you disable TLS 1.1 from a security point of view, too.
Isn’t TLS 1.2/1.1 used as default?
But as you know, some people still operate on systems that would make my grandmother blush. These operating systems may not be compatible with newer TLS versions. And if you have left older TLS versions open on your server, connections will be established over them. This would be a violation of PCI DSS requirements, and you could be reprimanded heavily.
So, ultimately, the onus is on you my webmaster friends. Pull out your calendars and mark the date—June 30, 2018.
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018in Hashing Out Cyber Security
How to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chromein Everything Encryption
Re-Hashed: How to Fix SSL Connection Errors on Android Phonesin Everything Encryption
Cloud Security: 5 Serious Emerging Cloud Computing Threats to Avoidin ssl certificates
This is what happens when your SSL certificate expiresin Everything Encryption
Re-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Messagein Hashing Out Cyber Security
Report it Right: AMCA got hacked – Not Quest and LabCorpin Hashing Out Cyber Security
Re-Hashed: How to clear HSTS settings in Chrome and Firefoxin Everything Encryption
Re-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithmsin Everything Encryption
The Difference Between Root Certificates and Intermediate Certificatesin Everything Encryption
The difference between Encryption, Hashing and Saltingin Everything Encryption
Re-Hashed: How To Disable Firefox Insecure Password Warningsin Hashing Out Cyber Security
Cipher Suites: Ciphers, Algorithms and Negotiating Security Settingsin Everything Encryption
The Ultimate Hacker Movies List for December 2020in Hashing Out Cyber Security Monthly Digest
Anatomy of a Scam: Work from home for Amazonin Hashing Out Cyber Security
The Top 9 Cyber Security Threats That Will Ruin Your Dayin Hashing Out Cyber Security
How strong is 256-bit Encryption?in Everything Encryption
Re-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3in Everything Encryption
How to View SSL Certificate Details in Chrome 56in Industry Lowdown
PayPal Phishing Certificates Far More Prevalent Than Previously Thoughtin Industry Lowdown