From SSL and early TLS to TLS 1.2: Creating a PCI DSS 3.1 migration plan

The problem with SSL and early TLS

The SSL protocol first appeared in 1995, and SSL 3.0 -- released in 1996 -- became the de facto standard for providing communication security over the Internet. For many years, attacks against SSL focused on implementation issues, but recently discovered vulnerabilities, such as POODLE and FREAK, are direct attacks on the SSL protocol itself.

Simply put, weak encryption protocols can't be used as a security control for the protection of payment data.

Version 3.1 of SSL was released as Transport Layer Security (TLS) 1.0 in 1999. While it introduced security improvements to mitigate weaknesses found in earlier versions, TLS version 1.0 -- and, in some cases, 1.1 -- are now no longer considered to be strong enough.

Simply put, weak encryption protocols can't be used as a security control for the protection of payment data, which has a direct impact on the following PCI DSS requirements:

• Requirement 2.2.3: Implement additional security features for any required services, protocols or daemons that are considered to be insecure.
• Requirement 2.3: Encrypt all non-console administrative access using strong cryptography.
• Requirement 4.1: Use strong cryptography.

Creating a migration plan to TLS 1.2

Critical vulnerabilities in such widely used encryption protocols pose a real threat to payment data security, particularly as there is no easy way to patch them. This is why the PCI SSC wants organizations to act immediately. Some critics argue PCI DSS certification is a checkbox exercise -- which is possibly why the SSC wants merchants to not only phase out SSL and early TLS use by June 30, 2016, but to also provide their PCI DSS assessor with a formal risk mitigation and migration plan, which details how they will make the transition. This requirement will ensure those affected are aware of the risk, and don't end up having to migrate their infrastructures at the last minute.

While the best response is to disable SSL entirely and migrate to TLS 1.2, this obviously will take time, which is why an enterprise's formal Risk Mitigation and Migration Plan -- as outlined by PCI DSS 3.1 -- has to describe how the risks associated with SSL will be mitigated until the migration is complete. Additionally, to ensure SSL is not implemented in new environments, there has to be a description of the processes for new vulnerability monitoring and of change control processes.

While the best response is to disable SSL entirely and migrate to TLS 1.2, this obviously will take time.

The SSC's PCI information supplement, Migrating from SSL and Early TLS, provides guidance and examples of information to be documented in the plan, along with migration recommendations and alternative options for strong cryptographic protocols. Further useful guidance on secure TLS configurations is provided in the National Institute for Standards and Technology Special Publication 800-52, which also recommends government agencies develop migration plans to TLS 1.2.

Enterprises should use audits, as well as internal and external vulnerability scans to identify insecure SSL implementations. In many cases, it will just be a case of disabling the use of SSL 3.0 and TLS 1.0, as most software now supports TLS 1.1 and TLS 1.2. For example, the most popular Web servers and browsers all support TLS. Additionally, administrators can use Group Policy to disable SSL 3.0 and TLS 1.0, and enable TLS 1.1 and TLS 1.2 for Internet Explorer.

Users must upgrade software or older devices that only support SSL 3.0 -- which may well be the case with third-party point-of sale-systems. Organizations that can't completely migrate away from SSL/early TLS will need to follow the PCI DSS Addressing Vulnerabilities with Compensating Controls process to verify affected systems are not susceptible to SSL vulnerabilities.

Besides upgrading to a secure version of TLS, merchants can deploy additional cryptographic measures, such as using field-level or application-level encryption to encrypt payment data prior to transmitting it, or implementing a strongly encrypted session, such as an IPsec  tunnel, before sending data over SSL.

As always, defense in depth is the best way to protect against current and future threats, and it also reduces the need to instantly patch critical vulnerabilities.

Finally, migration plans should take into account that TLS version 1.3 may well be released before the PCI SSC's June 30, 2016 deadline; it's currently a draft specification being worked on by the Transport Layer Security Working Group of the Internet Engineering Task Force (IETF).

Hopefully by then, the common, but confusing practice of using SSL to refer to TLS will start to disappear.

About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. He was also formerly a Microsoft Certified Database Manager and a registered consultant with the CESG Listed Advisor Scheme (CLAS). Mike has a passion for making IT security best practices easier to understand and achievable. His website offers free security posters to raise employee awareness of the importance of safeguarding company and client data and of following good practices.