Is your organization still using the SSL/early TLS protocols? Do you work with online and e-commerce partners or customers who haven’t yet started the migration away from SSL/early TLS to a more secure encryption protocol? Read on for key questions and answers that can help with saying goodbye to SSL/early TLS and reducing the risk of being breached.
What happens on 30 June 2018?
30 June 2018 is the deadline for disabling SSL/early TLS and implementing a more secure encryption protocol – TLS 1.1 or higher (TLS v1.2 is strongly encouraged) in order to meet the PCI Data Security Standard (PCI DSS) for safeguarding payment data.
What is SSL/early TLS?
Transport Layer Security (TLS) is a cryptographic protocol used to establish a secure communications channel between two systems. It is used to authenticate one or both systems, and protect the confidentiality and integrity of information that passes between systems. It was originally developed as Secure Sockets Layer (SSL) by Netscape in the early 1990s. Standardized by the Internet Engineering Taskforce (IETF), TLS has undergone several revisions to improve security to block known attacks and add support for new cryptographic algorithms, with major revisions to SSL 3.0 in 1996, TLS 1.0 in 1990, TLS 1.1 in 2006, and TLS 1.2 in 2008.
What is the risk of using SSL/early TLS?
There are many serious vulnerabilities in SSL and early TLS that left unaddressed put organizations at risk of being breached. The widespread POODLE and BEAST exploits are just a couple examples of how attackers have taken advantage of weaknesses in SSL and early TLS to compromise organizations.
According to NIST, there are no fixes or patches that can adequately repair SSL or early TLS. Therefore, it is critically important that organizations upgrade to a secure alternative as soon as possible, and disable any fallback to both SSL and early TLS.
Who is most susceptible to SSL/early TLS vulnerabilities?
Online and e-commerce environments using SSL and early TLS are most susceptible to the SSL exploits, but the 30 June 2018 PCI DSS migration date applies to all environments - except for payment terminals (POIs) (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.
Are there any considerations for payment terminals (POIs)?
As POIs may not be as susceptible to the same known vulnerabilities as browser-based systems, after 30 June 2018, POI devices (and the termination points to which they connect) that can be verified as not being susceptible to any of the known exploits for SSL and early versions of TLS may continue to use SSL /early TLS.
If SSL/early TLS is used, the POIs and their termination points must have up-to-date patches, and ensure only the necessary extensions are enabled.
Additionally, use of weak cipher suites or unapproved algorithms – e.g., RC4, MD5, and others – is not allowed.
What should organizations do if their ASV scan flags the presence of SSL and the scan fails?
Between now and 30 June 2018 organizations that have not completed their migration should provide the Approved Scanning Vendor (ASV) with documented confirmation that they have implemented a Risk Mitigation and Migration Plan (see Migrating from SSL/Early TLS for information on this) and are working to complete their migration by the required date. Receipt of this confirmation should be documented by the ASV as an exception under “Exceptions, False Positives, or Compensating Controls” in the ASV Scan Report Executive Summary.
What can and should organizations do now to protect themselves against SSL and early TLS vulnerabilities?
While 30 June 2018 is still a year away, it takes time to migrate to more secure protocols and organizations should not delay:
- Migrate to a minimum of TLS 1.1, preferably TLS 1.2. While it is possible to implement countermeasures against some attacks on TLS, migrating to a later version of TLS (TLS 1.2 is strongly encouraged) is the only reliable method to protect against the current protocol vulnerabilities.
- Patch TLS software against implementation vulnerabilities. Implementation vulnerabilities, such as Heartbleed in OpenSSL, can pose serious risks. Keep TLS software up-to-date to ensure it is patched against these vulnerabilities, and have countermeasures for other attacks.
- Configure TLS securely. In addition to providing support for later versions of TLS, ensure the TLS implementation is configured securely. Ensure that secure TLS cipher suites and key sizes are supported, and disable support for other cipher suites that are not necessary for interoperability. For example, disable support for weak “Export-Grade” cryptography, which was the source of the recent Logjam vulnerability.
- Use PCI SSC resources. Visit the PCI SSC website for resources that can help with SSL/early TLS migration, including detailed guidance, a webinar and a number of FAQs.
