The PCI Security Standards Council has announced that it is extending the migration completion date for transitioning from SSL and early TLS to a secure version of TLS (currently v1.1 or v1.2) from June 2016 to June 2018. The extended migration date was provided by the PCI Council as of December 2015 and supersedes the original dates issued in both PCI DSS v3.1 and in the “Migrating from SSL and early TLS” information supplement document in April 2015.
The PCI DSS v3.0 was released in November 2013 and was effective from January 2014, but just a few months after, in April, NIST talked about an issue deprecating the use of SSL and early TLS. In that version of the Standard, SSL/TLS was used as an example of strong cryptography to be used for administrative access, as well as for creation of secure communication channels between an organization and his payment processor. It was also used as an example for providing additional security to insecure services and as a form of compensation control to mitigate vulnerabilities on such weak protocols.
After that, the PCI Council listened to industry feedback and, in April 2015, published an updated version of the standard PCI DSS, the v3.1, which provided guidance and encouragement for organizations to migrate to a newer version of the protocol.
When the PCI Council released v3.1 of the PCI DSS, they received lots of feedback on that the issues were technically easy to accomplish, however not the migration plan. Migrating to TLS – or, to the last version of the protocol – was not in fact the real challenge: as they learned from many organizations and stakeholders who were evaluating the implementation of those changes, there is a complex business issue associated with that change which is greater than the technical one. This led them to ask for more time, in order to evaluate the risk and take the relevant action to mitigate it.
From that point on, the PCI Council worked with their stakeholders to make sure that they were actually doing the right thing in a comprehensive and sensible way, with an actual look at the marketplace and its needs, though also keeping in mind how it relates to Security. The PCI Council then issued new guidance later in 2015 and now they are looking to modify the PCI DSS Standard from 2016 to reflect some of those changes.
To get more technical, the TLS is a cryptographic protocol used to encrypt and authenticate communications between systems. It was originally developed as SSL (Secure Socket Layer) by Netscape in the early ’90s, then standardized by the IETF (Internet Engineering Task Force) and revised several times in order to improve security, block known attacks and to support new cryptographic algorithms. The most recent revision was in 2008 with the TLS v1.2. Because of its widespread use online, SSL and TLS have been targeted by both security researchers and attackers. Many vulnerabilities in SSL and TLS have been uncovered over the past twenty years, however only in recent years have researchers demonstrated practical attacks against these vulnerabilities.
Generally speaking there are three classes of vulnerabilities in SSL and TLS:
- The first category involves the cryptographic system. Both the TLS and SSL protocols warn about safely using cryptographic algorithms. For instance, the recent POODLE attack relies on a vulnerability affecting the way SSL version 3 uses cipher block chaining mode.
- The second category involves the implementation within specific software. For instance, the HEARTBLEED vulnerability in OpenSSL is as an example of vulnerability at an implementation level.
- The third category involves configuration. The use of weak cipher suites and weak key sizes are good examples of such issues. It is also worth mentioning the recent LOGJAM attack, exploiting systems that support weak export-grade cryptography.
The impact of the above vulnerabilities is such that, in many cases, those attacks could allow successful man-in-the-middle attacks that leave attackers decrypt or inject pieces of sensitive information. In some of the most serious cases, attackers could even steal long-term cryptographic keys.
What can we do about this?
Whilst it is possible to implement countermeasures against some of the attacks on TLS, migrating to later versions of TLS – in particular TLS version 1.1 and 1.2 – is the only reliable method to protect yourself from protocol-level vulnerabilities. The best recommendation for organizations is to disable SSL and early TLS and to move to TLS v1.1 or v1.2.
Implementation vulnerabilities such as HEARTBLEED in OpenSSL can pose serious risks, so always keep your software up-to-date, ensure you suitably patch these vulnerabilities and have countermeasures in place for other attacks.
Finally, in addition to providing support for later versions, ensure that your TLS implementation is configured securely to confirm that you are supporting secure cypher suites and key sizes and disable support for cipher suites that are not necessary for interoperability.
Now you have some extra time for planning the migration. However, never forget that there is a risk associated to a potential flaw in the IT systems supporting your business: put high priority on managing it.