Why older TLS protocols are unsafe for your organization?

In the early 1990s, Netscape began developing SSL; therefore, an initial draft was submitted for SSL v2.0 in 1995. SSL v2.0 had major security flaws that led to the creation of SSL v3.0. The draft for SSL v3.0 was submitted to the IETF in 1996. In Netscape’s words, SSL v3.0 could be a security protocol that prevents eavesdropping, tampering, or message forgery over the Internet. The IETF published RFC 61012 (Request for Comment) as specification for SSL v 3.0.

SSL began to be known as TLS, and the next version of TLS came in 1999 with RFC 22463. In a nutshell, SSL v 3.0 and TLS 1.0 don’t have variations that a developer should worry about; however, it’s better to use TLS 1.0. The next version of TLS, TLS 1.1, came into existence in 2006 and is outlined in RFC 43464. TLS 1.1 has enhancements over TLS 1.0. The next version, TLS 1.2, was released in 2008 and is defined through RFC 52465.

TLS 1.2 has had major changes since TLS 1.1, and it includes support for newer and secure cryptographic algorithms. In August 2018, TLS 1.3 was released. The differences between TLS 1.2 and 1.3 are extensive and significant, improving each performance and security. Simultaneously, TLS 1.2 remains in widespread use given its absence of known vulnerabilities and its continued usage in enterprise environments.

Outdated TLS versions

Sensitive data always require robust protection. TLS protocols provide confidentiality, integrity, and often authenticity protections to information while in transit over a network. This can be achieved by providing a secured channel between a server and a client to communicate for a session. Over time, new TLS versions are developed, and some of the previous versions become outdated for vulnerabilities or technical reasons; and, therefore, should no longer be used to protect data.

TLS 1.2 or TLS 1.3 should be used, and any organizations should not use SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1.

Outdated Cipher suits

In TLS 1.2, the term “cipher suites” refers to the negotiated and agreed-upon set of cryptographic algorithms for the TLS transmission. The TLS client offers a list of cipher suites, and the server selects negotiated cipher suites from the list. The cipher suites in TLS 1.2 consist of an encryption algorithm, a key exchange algorithm, an authentication mechanism, and a key derivation mechanism.

Cipher suites are identified as obsolete when one or more of the mechanisms is weak. Fragile encryption algorithms in TLS 1.2 are defined as NULL, RC2, RC4, DES, IDEA, and TDES/3DES; organizations should not use cipher suits with these algorithms. TLS 1.3 removes these cipher suites, but implementations supporting TLS 1.3 and organizations should check TLS 1.2 for obsolete cipher suites.

Outdated Key exchange mechanisms

Weaker key exchange mechanisms indicated by cipher suite include those designated as EXPORT or ANON. Cipher suites that use these key exchange mechanisms should not be used. In TLS sessions, even if the cipher suite is acceptable, key exchange mechanisms may use weak keys that allow exploitation. TLS key exchange methods include RSA key transport and DH or ECDH key establishment.

DH and ECDH have static as well as ephemeral mechanisms. NSA recommends RSA key transport and ephemeral DH (DHE) or ECDH (ECDHE) mechanisms, with RSA or DHE key exchange using at least 3072-bit keys and ECDHE key exchanges using the secp384r1 elliptic curve. For RSA key transport and DH/DHE key exchange, keys less than 2048 bits should not be used, and ECDH/ECDHE using custom curves should not be used.

Risk of outdated TLS protocols

Outdated TLS protocols use cipher suites that are not supported or recommended, and using older TLS versions would require effort to keep the libraries and drive up the cost of product maintenance. Apart from the above-discussed scenario, some additional ones can be:

Using outdated TLS versions would force organizations to use outdated, vulnerable cipher suites and not support newer recommended cipher suits.
TLS 1.0 and 1.1 are vulnerable to downgrade attacks since they rely on SHA-1 hash for the integrity of exchanged messages. Even authentication of handshakes is done based on SHA-1, which makes it easier for an attacker to impersonate a server for MITM attacks. TLS 1.1 or below does not provide the option to select more robust hashing algorithms, which the newer protocols do.
Supporting older protocols drive up cost as all vulnerabilities need to be patched, libraries need to be supported, and the attack surface increases.

Identifying and analyzing outdated TLS protocols

Since there are many ways that obsolete TLS configurations may be exhibited in traffic, the following detection strategy is recommended. Signatures can be simplified using this strategy:

First, identify the client’s offering and servers negotiating obsolete TLS versions. If a client offers or a server negotiates SSL 2.0, SSL 3.0, or an outdated TLS version, no further traffic analysis is required, and remediation strategies should be employed.
Next, for sessions using TLS 1.2, organizations should identify and remediate devices using obsolete cipher suites. Identify clients only offering and servers negotiating outdated TLS cipher suites and update their configurations to be compliant.
Finally, organizations should identify and remediate devices using weak key exchange methods for sessions using TLS 1.2 or TLS 1.3 and recommended cipher suites.

Benefits of upgrading to newer protocols

Apart from getting rid of vulnerabilities and having better security for the environment, organizations do tend to gain a few benefits by upgrading to newer protocols:

Increase performance in the overall environment.
Improved security.
Better support and patches for the vulnerabilities found, along with research for new vulnerabilities.
Better hashing algorithms for integrity check and authentication of handshakes.

Conclusion

Organizations encrypt network traffic to protect data in transit. However, using obsolete TLS configurations provides a false sense of security since it looks like the data is protected, even though it is not. Organizations should plan to discontinue outdated TLS configurations in the environment by detecting, remediating, and then blocking obsolete TLS versions, cipher suites, and key exchange methods.