PCI 3.1 SSL 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.”

Gary Glover, Director of Security Assessments
Gary Glover
SVP, Assessments
UPDATE: As of May 2017, PCI DSS 3.2.1 is the latest standard. Read more about the 3.2.1 updates.

June 30, 2018 is the deadline for merchants to disable SSL/early TLS and implement a more secure encryption protocol. TLS 1.1 or higher is required (TLS v1.2 strongly encouraged).


In April of 2015, the Payment Card Industry Security Standards Council (PCI SSC) released an unscheduled and important update: PCI DSS version 3.1. While it did include minor clarifications and additions, PCI 3.1 was primarily released to address the insecurity of Secure Sockets Layer (SSL) and some Transport Layer Security (TLS) encryption protocols.

After the release of PCI 3.1, all SSL and early TLS versions were not (and still are not) considered strong cryptography.

SSL and TLS encrypt the information sent between web browsers and web servers. Since the release of SSL v3, unfixable vulnerabilities were identified. You may have heard of some of these vulnerabilities back in 2014, including FREAK, POODLE, and WinShock.

The point is, the PCI Council has deemed that SSL and early TLS will no longer protect cardholder data.
PCI 3.1 SSL TLSSince the April 2015 update, merchants were not allowed to implement any new technology relying on SSL or early TLS (version 1.0 and sometimes 1.1, depending on use and implementation). Merchants already using systems and devices that utilize SSL and TLS must discontinue the use of those systems and devices before June 30, 2016.

The PCI DSS v3.1 requirements directly affected are:
  • Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons considered 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.

Each of these requirements will have additional sub-requirements or guidance provided in the latest version of the PCI DSS.

How will PCI 3.1 affect SecurityMetrics customers?

SecurityMetrics has been scanning for SSL vulnerabilities for over a decade. Specifically, we have been scanning for SSL version 3 vulnerabilities, such as the POODLE vulnerability, since October 2014.
    PCI 3.1 SSL TLS
  • SecurityMetrics vulnerability scans do not currently fail merchants using SSL or TLS 1.0 as long as they have provided documentation showing they have a TLS Mitigation and Migration plan.
  • This exception will expire when the June 30, 2018 deadline hits. Customers that have not disabled SSL and Early TLS and rescanned by that date may be knocked out of compliance due to a failing scan contact SecurityMetrics Support if you have questions. 
Follow for more data security articles like this

What about HTTPS and ecommerce?

Because virtually all ecommerce websites have SSL/TLS enabled for their cryptography, they are at the highest risk from SSL/TLS vulnerabilities. New e-commerce websites must not use or support SSL/early TLS.

The PCI Council also stated that web browsers will begin prohibiting SSL connections in the near future, preventing users from accessing web servers that haven’t migrated to a more modern protocol.


What about my POS/POI terminal?

The PCI Council decided that Point of Sale (POS) or Point of Interaction (POI) devices that aren’t susceptible to all known exploits of SSL and early TLS may continue to be used, even after the deadline.

Merchants who continue using old POS or POI devices should understand that because SSL is outdated technology, it may be subject to future security vulnerabilities. The PCI Council recommends that POI environments update to TLS v1.1 or later if possible.

How do I know if I’m using SSL/early TLS?

SSL and TLS are widely used, so I recommend contacting your terminal providers, gateways, service providers, vendors, and acquiring bank to determine if the applications and devices you use have this encryption protocol. If you’re writing your own software, please check with your development department.

Examples of applications that likely use SSL/early TLS
  • Virtual payment terminals
  • Back-office servers
  • Web/application servers

What if I’m using SSL/early TLS?

The PCI Council has released guidance on migrating from SSL and TLS, as well as examples and recommendations on how to deal with this requirement in their Migrating from SSL and Early TLS information supplement.

If you use SSL/early TLS, but don’t need to:

If you have existing implementations of SSL and early TLS that you don’t need for regular business operations, immediately remove or discontinue all instances of SSL/TLS. Do not use any new technologies that use SSL/TLS.

If you use SSL/early TLS, and need to continue using:

First, remember not to implement any new technologies that use SSL/TLS. But, if you need to continue using SSL/early TLS to continue regular business operations, here are some examples of what you can do:
  • Upgrade to a current, secure version of TLS configured to not accept fallback to SSL or early TLS.
  • Encrypt data with strong cryptography before sending over SSL/early TLS (for example, use field-level or application-level encryption to encrypt the data prior to transmission)
  • Set up a strongly-encrypted session first (e.g. IPsec tunnel), then send data over SSL within the secure tunnel
  • Check firewall configurations to see if SSL can be blocked
  • Check all application and system patches are up to date
  • Check and monitor systems to ID suspicious activity that may indicate a security issue
Please note that organizations with existing implementations of SSL and early TLS must have a Risk Mitigation and Migration Plan in place. According to the PCI Council, this document will “detail [your] plans for migrating to a secure protocol, and also describes controls [you have] in place to reduce the risk associated with SSL/early TLS until the migration is complete.”

You will need to provide your Risk Mitigation and Migration Plan to your PCI assessor as part of the PCI DSS assessment process.

Learn more about the Risk Mitigation and Migration Plan in the PCI Council’s migrating from SSL and Early TLS information supplement.

Need help discontinuing the use of SSL/TLS? Contact our PCI support team.

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Senior Vice President of Security Assessments at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.


3 comments:

  1. Cutting out TLS 1.0 support pretty much cuts out every IE browser before IE 11. This includes Windows 7 and 8. Everything before IE 11 either doesn't support TLS 1.0 or doesn't have it enabled by default.

    Do you have any idea how many users there are out there that have no idea how to enable such an option? IE 8, 9 and 10 comprise of 30% of the market. So to disable a cipher that either isn't even avail in a browser or isn't even enable by default is pretty absurd.

    ReplyDelete
    Replies
    1. 30% of the market will upgrade very quickly when much of the internet no longer works in their ancient browsers.

      Delete
    2. Andrew, I wouldn't be so sure. Anyone who is still running an XP machine will have IE 8. Also, the real issue is mostly large corporations that don't update browsers due to legacy support

      Delete