June 28, 2017

Are You Still Using Early TLS? It’s Time to Take Action!

Are You Still Using Early TLS? It’s Time to Take Action!

By Stephen Ames, CISA, CISSP – Senior Director, Security Compliance, Shift4 Corporation

Update 05/10/2018: Beginning May 10, 2018, Shift4 Payments will be officially ending support of TLS versions 1.1 and earlier. If you are a merchant still using one of these unsupported versions,  you will not be able to use any of our gateway services. Please contact Shift4’s Customer Support team immediately at 702.597.2480, option 2, or email [email protected].
We are rapidly approaching a day that I hope will not “live in infamy.” June 30, 2018. This is the day we must shut down early TLS on all of our production gateway interfaces.

Why should you care? Because you may not be able to process payments through Shift4’s systems after June 30, 2018. Fortunately, there will be no impact on UTG-encrypted transactions.

I encourage you to get this article to your IT support staff and/or your PMS/POS system vendor. Suffice it to say that if your PMS or POS system is using TLS 1.0, you have about a year to either modernize it to use TLS 1.2, or replace it.

I first warned you about using early TLS back in July 2016. If you are new to the payments industry or have forgotten about the cutoff date for early TLS usage, I encourage you to go back and review my previous Executive Insight on this subject. I’m nudging everyone toward using TLS 1.2. Remember, TLS 1.2 itself is an 8-year-old spec – an eternity in IT lifecycle terms – and it too has cipher suites that are no longer considered secure.

Before I go any further, let’s review some basic terminology:

  • SSL and TLS (or Secure Sockets Layer and Transport Layer Security): SSL and TLS are protocols used to encrypt communication between a client (or a browser) and a web server or application server. The SSL protocol has been deprecated in favor of the more secure TLS protocol.
  • Cipher Suite: A cipher suite is a set of cryptographic algorithms that specifies a unique algorithm for key exchange, bulk encryption, and message authentication as well as the protocol in use.
  • Key Exchange: Key exchange algorithms are used to protect information required to create shared keys. The algorithms are asymmetric, and are generally used for small amounts of data.
  • Bulk Encryption: Bulk encryption algorithms encrypt the messages exchanged between clients (or browsers) and servers. The algorithms are symmetric and are generally used for large amounts of data.
  • Message Authenticator: Message authentication algorithms generate message hashes and signatures to ensure integrity of the message.

So exactly what is early TLS? The PCI Security Standards Council’s definition is 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 3-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 unfortunately, early TLS is not that easy to define.

Shift4’s definition of early TLS is as follows: 1) TLS 1.0, 2) encryption algorithms with key strengths of less than 128-bits, and 3) vulnerable cipher suites. The following cipher suites are currently in production.

  TLS 1.0, 1.1, 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 
  TLS 1.0, 1.1, 1.2  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 
  TLS 1.0, 1.1, 1.2  TLS_RSA_WITH_AES_128_CBC_SHA 
  TLS 1.0, 1.1, 1.2  TLS_RSA_WITH_AES_256_CBC_SHA  

So, what will happen on June 30, 2018? As of this writing, we will be forced to shut down TLS 1.0 or risk operating as a noncompliant Level 1 Service Provider. Since that date falls on a Saturday, we will perform this action earlier that week, as we don’t make significant changes in production on weekends or around holidays.

Again, it is extremely important that you get in touch with your IT support staff and/or your PMS/POS system vendor and have them ensure you will not be affected when we shut down TLS 1.0 during the last week of June 2018.

As always, feel free to reach out to me directly at [email protected] for clarification on the information I provided here or with any other questions that you may have.