The time to migrate is now.
For over 20 years Secure Sockets Layer (SSL) has been in the market as one of the most widely-used encryption protocols ever released, and remains in widespread use today despite various security vulnerabilities exposed in the protocol.
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.
SSL has been removed as an example of strong cryptography in the PCI DSS, and can no longer be used as a security control after June 30, 2016.
What is the risk?
SSL/TLS encrypts a channel between two endpoints (for example, between a web browser and web server) to provide privacy and reliability of data transmitted over the communications channel. Since the release of SSL v3.0, several vulnerabilities have been identified, most recently in late 2014 when researchers published details on a security vulnerability (CVE-2014-3566) that may allow attackers to extract data from secure connections. More commonly referred to as POODLE (Padding Oracle On Downgraded Legacy Encryption), this vulnerability is a man-in-the-middle attack where it’s possible to decrypt an encrypted message secured by SSL v3.0.
The SSL protocol (all versions) cannot be fixed; there are no known methods to remediate vulnerabilities such as POODLE. SSL and early TLS no longer meet the security needs of entities implementing strong cryptography to protect payment data over public or untrusted communications channels. Additionally, modern web browsers will begin prohibiting SSL connections in the very near future, preventing users of these browsers from accessing web servers that have not migrated to a more modern protocol.
How should I respond?
The best response is to disable SSL entirely and migrate to a more modern encryption protocol, which at the time of publication is a minimum of TLS v1.1, although entities are strongly encouraged to consider TLS v1.2. Note that not all implementations of TLS v1.1 are considered secure – refer to NIST SP 800-52 rev 1 for guidance on secure TLS configurations.
What this means for PCI DSS
In PCI DSS v3.1, SSL and early TLS are no longer examples of strong cryptography or secure protocols. The PCI DSS v3.1 requirements directly affected are:
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 and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
SSL and early TLS are not considered strong cryptography and cannot be used as a security control after 30th June, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. Effective immediately, new implementations must not use SSL or early TLS. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after 30th June, 2016.
Download the PCI-DSS Information Supplement