June 30 Marks the End of SSL and Early TLS. Here’s What You Need to Know.
By: Stephen Ames, VP of Compliance, Shift4 Payments
We in the payments industry are rapidly approaching a day that I hope will not “live in infamy.” June 30, 2018. This is the day that SSL and early versions of TLS will finally and officially be put to rest on payment processing interfaces. If you haven’t taken the proper steps, you may find yourself unable to process payments after that date.
Here’s what you need to know about the technologies themselves and the fast-approaching shutdown.
What Are SSL and Early TLS?
SSL, or Secure Sockets Layer, refers to a type of data encryption that was once used to secure communications between a user’s web browser and a web server in order to protect transmitted data from eavesdropping or tampering. Early TLS, or Transport Layer Security, refers to versions 1.0 and 1.1 of the encryption technology, themselves 18- and 11-year-old protocols, respectively – ancient by IT terms. TLS 1.0 and some cipher suites in TLS 1.1 are deemed insecure by the PCI Security Standards Council (PCI SSC) and the National Institute of Standards and Technology (NIST).
Indeed, some scary TLS exploits have been documented over the last decade. For example, there are several vulnerabilities that, when exploited by cybercriminals, can create an opportunity for “man-in-the-middle” attackers to break into a system and remain undetected, all while “eavesdropping” and gathering data as users communicate with each other. Another one of these vulnerabilities can potentially allow remote hackers to break into the system and cause a denial of service (DoS) error, which crashes the device and renders the payment network unusable.
Making Sense of It All
So how do you know if “early TLS” is being used in your payment processing environment? Well, that can be a little tricky to figure out. The PCI SSC’s own definitions of SSL and TLS are vague and based on PCI DSS version 3.1, which was superseded by version 3.2 in April 2016. They refer the reader to NIST Special Publication 800-52 Revision 1, which is itself a 4-year-old document, not to mention a common cure for insomnia. The SSC’s supplemental guidance on Migrating from SSL and Early TLS provides a fleeting definition:
“Fifteen years ago, SSL v3.0 was superseded by TLS v1.0, which has since been superseded by TLS v1.1 and v1.2. To date, SSL and early TLS no longer meet minimum security standards due to security vulnerabilities in the protocol for which there are no fixes. It is critically important that entities upgrade to a secure alternative as soon as possible, and disable any fallback to both SSL and early TLS.”
To further complicate things, let’s review PCI DSS Requirement 4.1:
“Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks…”
We then find the definition of strong cryptography in the PCI DSS Glossary:
“Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is “one way”; that is, not reversible). It is recommended that all new implementations use a minimum of 128-bits of effective key strength.”
The reader is then referred to yet another NIST Special Publication – 800-57 Part 1, Revision 4 this time. Are you still with me? At this point, we still don’t have a clear definition of early TLS. We can’t simply say early TLS is TLS 1.0.
Here’s why. All TLS versions have vulnerabilities, be it weak bulk encryption ciphers or man-in-the-middle exploits. For example, there’s a new variant of the original POODLE attack that exploits implementation flaws of CBC – Cipher Block Chaining – encryption ciphers. This is not an SSL 3.0 downgrade attack as previously noted. The Logjam attack exploits implementations of the Diffie-Hellman key exchange process. There are also a handful of exploits against RC4-based encryption ciphers. And the list goes on.
So as you can see, early TLS is not very easy to define – and unfortunately the burden will be on merchants still using the technologies after the June 30 deadline who suddenly find themselves out of compliance or unable to process any payments.
Why June 30, 2018?
When the PCI Data Security Standard (DSS) version 3.1 was released back in April 2015, the PCI SSC decreed that SSLv3 and early versions of TLS are no longer considered strong encryption for the transport of cardholder data over public networks or for non-console administrative access to your cardholder data environment (CDE). This means that if you’re still using SSLv3 and early versions of TLS as of June 30, 2016, your CDE may be non-compliant with PCI DSS – not to mention the fact that your payment security operations will be at risk.
The PCI SSC revised their standing on these protocols in April 2016 when they released PCI DSS version 3.2, which offered the following conditions for continued use of SSL and early TLS:
- You may continue using SSLv3 and early versions of TLS until June 30, 2018, but you must maintain a formal Risk Mitigation and Migration Plan.
- You may continue using SSLv3 and early versions of TLS for your card-present point-of-sale terminals beyond June 30, 2018, if it can be verified they are not susceptible to any known exploits for SSLv3 and early versions of TLS. You must also maintain a formal Risk Mitigation and Migration Plan. While this may be a viable option for merchants, it is not for Shift4 Payments because it cripples our commitment to deliver ironclad security for your transactions.
- Any new installations in your CDE may never use SSLv3 or early versions of TLS.
If you haven’t yet, I strongly encourage you reach out to your IT support staff and/or your PMS/POS system vendor to make sure you won’t be affected come the end of June. Suffice it to say that if your PMS or POS system is using TLS 1.0 or TLS 1.1, time is just about up to either modernize it to TLS 1.2, or replace your system. You can use our POS Solution Finder to identify compliant POS system options.