PCI DSS 3.1 and SSLv3: It’s best time to remove the 20 year old SSL protocol

Pierluigi Paganini May 08, 2015

To address the risk PCI DSS 3.1 updates requirements 2.2.3, 2.3 and 4.1 to remove SSL and early TLS as examples of strong cryptography.

 “The National Institute of Standards and Technology (NIST) has identified the Secure Socket Layers (SSL) v3.0 protocol as no longer being acceptable for protection of data due to inherent weaknesses within the protocol. Because of these weaknesses, no version of SSL meets PCI SSC’s definition of ‘strong cryptography,’ and revisions to the PCI Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA-DSS) are necessary” PCI SSC says.

The Payment Card Industry Security Standards Council (PCI SSC), which manages the standards has released PCI DSS 3.1 during April 2015. PCI DSS – Payment card industry Data Security Standard was formed during December 2004. Usually, Changes are made to the standards every three years, based on feedback from the Council’s global constituents per the PCI DSS and PA-DSS development lifecycle and in response to market needs.

Why PCI DSS v3.1?

Version 3.0 only took full effect from 1st January 2015, but in response to damaging vulnerabilities such as Heartbleed, Beast and POODLE, which take advantage of security holes in the SSL protocol, PCI SSC has decided to release the first version of PCI DSS 3.0. This version 3.1 will no longer consider SSL or early versions of TLS as strong cryptography, per requirement 2.3 and 4.1 when protecting cardholder data. This applies to the associated sections of PA-DSS as well.

Most SSL/TLS deployments support both SSL 3.0 and TLS 1.0 in their default configuration. Newer software may support SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. In these cases the software simply needs to be reconfigured. Older software may only support SSL 2.0 and SSL 3.0, in this case upgrading is the only option.

20 year old SSL 3.0

SSL v3.0 was defined in the year 1996. It is superseded by TLS protocol in 1999. As of 2014, the 3.0 version of SSL is considered insecure due to multiple vulnerabilities and weaknesses that were identified at the time. With the advent of POODLE (“Padding Oracle On Downgraded Legacy Encryption”), SSL 3.0 is quickly becoming deprecated.

Heartbleed vulnerability was a flaw in OpenSSL library, POODLE and BEAST are a browser based attacks which take advantage of flaw in the SSL 3.0 protocol itself, so it cannot be fixed with a software patch. Upgrading to the recent version of TLS is the best known way to remediate these vulnerabilities.

 

SSL/TLS is the most widely deployed encryption protocol. It is used in almost every application to ensure confidentiality whenever we need to transmit sensitive information.

SSL Labs APIs 1 PCI

The most common use of SSL/TLS is to secure websites (HTTPS), though it is also used to:

  • Secure email in transit (SMTPS or SMTP with STARTTLS, IMAPS or IMAP with STARTTLS)
  • Share files (FTPS)
  • Secure connections to remote databases and secure remote network logins (SSL VPN)

What does the standard recommend?

To address the risk, PCI DSS 3.1 updates requirements 2.2.3, 2.3 and 4.1 to remove SSL and early TLS as examples of strong cryptography.

  • Organizations with existing implementations have until June 30, 2016 to move to a secure version of TLS. Those organizations must also have a risk mitigation and transition plan.
  • Prior to this date, existing implementations that use SSL and/or early TLS must have a formal risk mitigation and migration plan in place. Guidance on interim risk mitigation approaches, migration recommendations and alternative options for strong cryptographic protocols is outlined in the PCI SSC Information Supplement: Migrating from SSL and Early TLS.
  • Point-of-sale (POS)/Point-of-interaction (POI) terminals (devices such as magnetic card readers or chip card readers that enable a consumer to make a purchase) that can be verified as not being susceptible to all known exploits for SSL and early TLS may continue using these protocols as a security control after 30 June 2016.

This gives organizations a very generous window to address this issue, which some organizations may require to address appliances, embedded systems, or large inventories of point-of-sale (POS) devices, which may take considerable time and effort to replace.

Depending on the software tools that is used within the business, one should either upgrade or reconfigure the software to run higher versions of TLS protocol

  • Upgrades: Contact the software vendor to purchase the latest version. During implementation, be sure to configure the software for the highest version of TLS available.
  • Reconfigurations: All you have to do is configure the software to disable SSL 3.0. Instructions on how to do this can usually be found on the vendor’s website or various help forums and blog posts on the Internet. The process will be different for each piece of software that you use.
About the Author Ashiq JA (@AshiqJA)
Ashiq JA (Mohamed Ashik) is a Cyber Security Researcher and Writer passionate about Web Application Security, Security research using Machine Learning and Big Data, Deep web, Security technologies and Threat Analysis. He is currently working as a Security Consultant for a financial firm. He believes in knowledge sharing as the best source for information security  awareness. To catch up with the latest news on InfoSec trends, Follow Ashiq JA on Twitter technologies and Threat Analysis. He is currently working as a Security Consultant for a financial firm. He believes in knowledge sharing as the best source for information security  awareness. To catch up with the latest news on InfoSec trends, Follow Ashiq JA on Twitter @AshiqJA.

Edited by Pierluigi Paganini

(Security Affairs –  APT, cyber espionage)



you might also like

leave a comment