Saying Goodbye to SSL

Does your website still use SSL or an early TLS protocol?  Are you an ecommerce or member only site or yet to start the migration away from SSL to a more secure encryption protocol? Read on for key questions and answers that can help with saying goodbye to SSL and TLSv1.1 and reducing the risk of being breached. 

What happens on 30 June 2018?

The 30th 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. Standardised 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, TLS 1.2 in 2008 and in March 2018 TLS 1.3.

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.

What should you do if your Security Scans flag 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?

If you have not already considered, it takes time to migrate to more secure protocols and organizations should not delay:

• Migrate to 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 or 1.3 is 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.

TLS 1.3 vs TLS 1.2

The Internet Engineering Task Force (IETF) is the group that has been in charge of defining the TLS protocol, which has gone through many various iterations. The previous version of TLS, TLS 1.2, was defined in RFC 5246 and has been in use for the past eight years by the majority of all web browsers. As of March 21st, 2018, TLS 1.3 has now been finalized, after going through 28 drafts.

Speed Benefits of TLS 1.3

TLS and encrypted connections have always added a slight overhead when it comes to web performance. HTTP/2 definitely helped with this problem, but TLS 1.3 helps speed up encrypted connections even more with features such as TLS false start and Zero Round Trip Time (0-RTT).

To put it simply, with TLS 1.2, two round-trips have been needed to complete the TLS handshake. With 1.3, it requires only one round-trip, which in turn cuts the encryption latency in half. This helps those encrypted connections feel just a little bit snappier than before.

Improved Security With TLS 1.3

A big problem with TLS 1.2 is that it’s often not configured properly it leaves websites vulnerable to attacks. TLS 1.3 now removes obsolete and insecure features from TLS 1.2, including the following:

• SHA-1
• RC4
• DES
• 3DES
• AES-CBC
• MD5
• Arbitrary Diffie-Hellman groups — CVE-2016-0701
• EXPORT-strength ciphers – Responsible for FREAK and LogJam

Because the protocol is in a sense more simplified, this make it less likely for administrators and developers to mis-configure the protocol.