Bring Out Your Dead: An Update on the PCI relevance of SSLv3

In October, a tidal wave of discussion surrounding SSLv3 hit the information security community with the release of the POODLE attack vector. This served to heat up existing discussions about when and how organizations would give SSLv3 the final thump on the head and put it out of its misery.

Thankfully, many organizations seized the opportunity to drop SSLv3 support in their products and services. We expect it will be a while before the majority of products and services to completely drop SSLv3 support, especially for vendors that don't already have an established update regime in place.

But recent statements from the PCI SSC will accelerate the process. The best practice of removing SSLv3 in favor of TLS is quickly evolving into a compliance mandate that many organizations will need to start dealing with this month.

Before we get started, note that upgrading from SSLv3 to TLS 1.1 or greater does not require new certificates. For more on the topic of certificates, head over to the Trustwave blog.

"Strong Encryption"

In reading the PCI DSS, one term you'll notice throughout is "strong encryption" (2.1.1.d, 4.1, 4.1.1 and 4.2). The term was chosen to allow for its definition to evolve over time with the advent of new encryption attack vectors and the required counter measures. This is the case with SSLv3, and the PCI SSC decided in February that SSLv3 no longer meets the definition of "strong encryption." This means that once the PCI DSS is updated, organizations can no longer expect to remain compliant if they continue to use SSLv3.

The PCI SSC has decided that TLS 1.1 or greater does equal strong encryption. We are encouraging organizations who haven't already begun this transition to act now to remove SSLv3 support from all their services and not just those that are in scope for PCI compliance.

Low Hanging Fruit

Big changes in any technology configuration can affect end users, so we wanted to highlight areas where we believe most organizations should start in ridding their network environments of SSLv3.

Finding web browsers that support TLS will not be a significant challenge for most organizations since nearly all mainstream, currently supported web browsers have provided support for TLS for quite some time.

Many of the most popular web servers in use, including Apache, IIS, and Nginx have also supported TLS for a while now. There is also a plethora of guidance publicly available that addresses the removal of SSLv3 from those configurations.

Sticks in the Mud

While some areas are easy to address, organizations will struggle in other areas to get technology up to par. These areas include technologies where the upgrade cycle is typically very slow or where security isn't yet of great concern.

These areas include:

• Point of Sale (PoS) Terminals
• Network infrastructure devices
• SSL VPN devices/services
• Embedded devices
• Non-browser client software (thick clients that use SSL)

These areas are challenging because their security life cycles tend to move slower than mainstream web servers and browsers. Also, these areas are generally not the first priority for organizations. That said, they are still an important areas for organizations to upgrade their SSLv3 configurations to TLS 1.1 or greater.

Knowing some services that will make the change slower than others, it's very important that organizations identify services that support SSLv3 so they can prioritize their efforts and determine which to address first.

How to identify SSLv3-enabled services?

Many network vulnerability scanners, especially ASV-certified scanners like Trustwave's TrustKeeper scan engine, already support the detection of SSLv3 services. Many organizations have already chosen to use this as a means to quickly pull together an inventory of SSLv3-enabled services and systematically upgrade or remove them from their Card Holder Data (CHD) environments.

Using the TrustKeeper scan engine, organizations can filter their results by the finding name "SSLv3 Supported" within their network scan results to build and maintain a working inventory, like so:

Another way for organizations to test for SSLv3 support on their systems is simply to connect to a service using OpenSSL's s_client functionality. This tends to be a bit more work because you need to know what services might support SSL and explicitly connect to them with openssl, like so:

• openssl s_client -ssl3 -connect 192.168.1.1:443

If SSLv3 is supported, you will see "Protocol : SSLv3" present in the command output. If not, it will likely error and fail to connect indicating SSLv3 is not supported.

The manual route includes some challenges such as nuanced complexities with protocols that don't simply wrap the entire destination protocol in an SSL/TLS tunnel, e.g., SMTP, FTP-S, IMAP-S, and many others. For these protocols, you may need to supply additional command-line parameters to fully verify whether SSLv3 is supported, like so:

• openssl s_client -starttls smtp -crlf -ssl3 -connect 10.70.33.110:25

Given these complexities, we strongly recommend that organizations make it easier on themselves by leveraging their existing vulnerability scanning technology to obtain and maintain their SSLv3 inventory.

Parting Thoughts

As mentioned before, many organizations' efforts to remove SSL configurations are already well underway. Those organizations that haven't started this process should know that upgrading from SSLv3 to TLS 1.1 or greater will soon become a PCI SSC mandate for organizations handling CHD. We look forward to providing further guidance and assistance to our customers and the community at large as they tackle this important transition.

References:

• https://www.pcisecuritystandards.org/pdfs/15_03_25_PCI_SSC_FAQ_SSL_Protocol_Vulnerability_Revisions_to_PCI_DSS_PAD.pdf
• http://training.pcisecuritystandards.org/pci-ssc-bulletin-on-impending-revisions-to-pci-dss-pa-dss-assessor
• https://www.pcicomplianceguide.org/pci-dss-v3-1-and-ssl-what-you-should-do-now/
• http://unix.stackexchange.com/questions/162478/how-to-disable-sslv3-in-apache
• https://zmap.io/sslv3/browsers.html
• http://www.tenable.com/blog/pci-ssc-announces-the-end-of-ssl-usage-for-the-payment-card-industry

****UPDATE – April 14, 2015****

Today the PCI SSC has announced that the PCI DSS 3.1 update will be published and effective tomorrow.

This update makes the following summary clarifications about the use of SSLv3 and TLS 1.0 in PCI relevant environments:

• New implementations must use alternatives to SSL and early TLS.
• Organizations with existing implementations of SSL and early TLS must have a risk mitigation and migration plan in place.
• Prior to June 30, 2016, Approved Scanning Vendors (ASVs) may document receipt of an organizations risk mitigation and migration plan as an exception in the ASV Scan Report (in accordance with the ASV Program Guide).
• Point of Sale (POS) or Point of Interaction (POI) devices that can be verified as not being susceptible to all known exploits of SSL and early TLS may continue to use these protocols as a security control after June 30, 2016.

****UPDATE – February 8, 2016****

The Payment Card Industry Security Standards Council (PCI SSC) announced in December that it is extending the migration completion date to June 30, 2018 for transitioning from SSL and TLS 1.0 communication protocols to a secure version of TLS (currently v1.1 or higher). The new date of June 2018 (replacing the June 2016 deadline) offers additional time to migrate to the more secure protocols, but waiting is not recommended. See the PCI SSC blog for more info: http://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls.