If your organization is required to comply with the Payment Card Industry-Data Security Standard (PCI-DSS), particularly Requirement 11, then you are likely familiar with the problems plaguing SSL, early TLS (i.e. TLSv1.0) and their supported ciphers over the past several months. High profile vulnerabilities such as HeartBleed, POODLE, FREAK and LogJam have sent merchants scrambling to patch external-facing systems within their cardholder data environment (CDE) to ensure their customer data is safe and they remain compliant with PCI-DSS.
SSL/TLS Cipher Suite Issues
One of the primary issues surrounding SSL and early TLS are the common cipher suite algorithms they support, specifically Cipher Block Chaining (CBC) and Rivest Cipher 4 (RC4). Although problems in these algorithms have been discussed for years, it only truly began affecting those who are required to have quarterly compliance scans by an Approved Scanning Vendor (ASV) in early 2011 when CVE-2011-3389 was published. This CVE, which has a Common Vulnerability Scoring System (CVSS) score of 4.3, described a vulnerability in CBC-based algorithms whereby an attacker could obtain clear text information from an encrypted HTTPS connection via a man in the middle-style of attack (also known as the ‘BEAST’ vulnerability). Since almost all web servers supported CBC algorithms at the time and the CVSS score of the vulnerability was 4.0 or greater, merchants suddenly began failing their ASV scans. Although most modern browsers later implemented a fix that would prevent this type of attack from happening, many merchants either changed their cipher preference order to prefer RC4 ciphers over CBC (as a compensating control) or simply disabled CBC ciphers altogether. Those that continued to support CBC ciphers would later be forced to disable them due to the POODLE vulnerability (CVE-2014-3566), which caused a scan failure for anyone supporting SSLv3 with CBC ciphers and several utilizing early TLS (CVE-2014-8730) with CBC ciphers.
Due to the aforementioned vulnerabilities and since support for RC4 was not generally considered grounds for a scan failure, many merchants turned to utilizing it for their cipher suite for SSLv3/early TLS. Even when a CVE affecting RC4 (CVE-2013-2566) was later released, at the time it only had a CVSS score of 2.6 which was below the failing threshold of 4.0. Although many merchants began to support the more secure TLSv1.1/1.2 for their websites, they continued to support SSLv3/early TLS utilizing RC4 ciphers for backward compatibility with older browsers.
The “Bar Mitzvah” Attack
The straw that broke the camel’s back for SSLv3/early TLS occurred in March 2015 at Black Hat Asia, a security conference known for its cutting edge security presentations. During this conference, a security researcher revealed details of the “Bar Mitzvah” attack which exploits a 13 year old weakness in the RC4 algorithm (hence the name “Bar Mitzvah”). Soon after the release of this exploit, the National Institute of Standards and Technology (NIST) increased the CVSS score for CVE-2013-2566 from 2.6 to 4.3, meaning support for RC4 or CBC ciphers, which was any merchant supporting SSLv3/early TLS, now caused a scan failure.
Updated PCI-DSS Requirements
Recognizing this issue, the PCI Security Standards Council (PCI-SSC) updated the PCI-DSS to v3.1 in April 2015. Among other updates, it states that SSL and early TLS are no longer considered to be strong cryptography and may not be used as a security control after June 30, 2016. Merchants must have stronger encryption mechanisms in place by that date or fail their quarterly ASV scans. In the meantime, merchants that have exiting SSL and/or early TLS implementations in place must have a formal risk mitigation and migration plan in order to pass quarterly ASV scans.
Moving Forward
Merchants should begin moving toward more secure encryption methodologies, such as TLSv1.2, as soon as possible. Since all modern Internet browsers support TLSv1.2 by default, this should not prove to be a major issue for clients of card merchants. The primary issue merchants will face is within its Application Programming Interfaces (APIs) and other applications that have older encryption methodologies hard coded within its applications. Merchants may need to overhaul existing applications in order to ensure they are compatible with TLS v1.2.
The PCI-SSC has published an information supplement that includes frequently asked questions and how to create a migration plan, available at https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf. This document will help you get started toward meeting the June 30, 2016, deadline and maintaining your PCI compliance.