TLS Protocols and Cipher Suites

Back

The Goal

Transport Layer Security (TLS) is a protocol used to protect information in transit between a client and a server. It prevents an attacker who is able to intercept messages from being able to read the contents of those messages. TLS supersedes an earlier protocol known as Secure Sockets Layer (SSL) and was released in 1999.

When configuring TLS there are several options that can be configured, from which protocol versions are enabled to which specific cipher suites are supported. The goal of this article is to highlight several known weaknesses in TLS configurations to enable a company to harden their systems against interception attacks.

Key Takeaways

Understand which cipher suites are known to be weak so that they can be avoided.
Understand the trade off when disabling specific cipher suites to balance compatibility with security.

The Trade Off

When it comes to selecting protocol versions and cipher suites to support, there is a trade off between security and compatibility. For example, very old systems may only support outdated protocol versions and so disabling these versions may mean that some users cannot access your system. However, when we say “very old” there is a further consideration, in that, you may in fact, not want users of ancient web browsers to visit your website due to other security concerns.

Protocol Versions

Disable Secure Sockets Layer

Secure Sockets Layer (SSL) was a protocol designed to protect traffic in transit, however it was superseded by Transport Layer Security (TLS) in 1999. SSL version 2.0 was prohibited in RFC 6176 released in 2011. SSL version 3.0 was deprecated in RFC 7568 released in 2015, which noted the protocol is “comprehensively broken”.

Therefore, the guidance for SSL is simple: it should be disabled. If you’re concerned by compatibility issues when disabling SSL, you should note that browser support for SSL was removed many years ago. Chrome removed SSL (and TLS fallback to SSL), in Chrome 32 released in November 2014. Firefox removed SSL in version 34 released December 2014. Internet Explorer disabled SSL for protected-mode sites in February 2015.

Vulnerability: SSL DROWN

Decrypting RSA with Obsolete and Weakened eNcryption (DROWN) is a vulnerability in systems that either:

present two services that use the same private key, where one of the services supports SSLv2 and the other service supports a more secure protocol version, or
a single service that supports both SSLv2 and a more secure protocol version and uses the same private key for both protocol versions.

This allows the threat actor to compromise the weaker cryptographic system and use that to impact the more secure service. It does this by allowing a threat actor to exploit a weakness in SSLv2 which leads to key information being leaked, this can then be used to attack the more secure protocol version.

Vulnerability: SSLv3 POODLE

The SSLv3 specification is vulnerable to an issue known as “POODLE” which is caused by the way SSLv3 handles the padding bytes when decrypting messages using block ciphers in CBC-mode. It can allow an attacker to decrypt a byte of cipher text in as few as 256 tries. This can be used to decrypt small pieces of repeated data, such as HTTP cookies.

Disable Early Transport Layer Security Versions

The term “Early TLS” is often used to refer to both TLSv1.0 and TLSv1.1 together. Both of these versions should be disabled. An Internet Draft to deprecated TLSv1.0 and TLSv1.1 was released in June 2018. Although, version 1.0 of this protocol was effectively deprecated when browsers announced their plan to remove support for the version.

As for compatibility concerns, it should be noted that Chrome has supported the more secure TLSv1.2 since August 2013 and Firefox has supported it since February 2014. Additionally, the browsers have removed support for early TLS entirely. For example, Chrome deprecated TLSv1.0 and TLSv1.1 in Chrome 72 and removed it in entirely Chrome 84. Firefox disabled early TLS by default in version 74.

As widespread support for TLSv1.2 has been available for more than a decade, the guidance here is simple: disable TLSv1.0 and TLSv1.1.

Transport Layer Security Version 1.3

A new version of TLS, version 1.3, was published in 2018 and has wide support by web browsers. TLSv1.3 offers several security and performance enhancements over earlier version of TLS. Additionally, browsers that do not support this version will fallback to TLSv1.2. Therefore, it is recommended that support for TLSv1.3 is enabled.

Cipher Suites

Forward Secrecy

Forward Secrecy is a feature of key agreement protocols that ensures that session keys will not be compromised even if the server private key is. Additionally, Perfect Forward Secrecy (PFS) can be achieved by generating a unique key per session, which will ensure if a single session key is compromised the other sessions will still be protected. RSA key-exchange does not provide forward secrecy. Therefore, any cipher suite that users RSA key exchange should be disabled in favour of Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE).

The following are just a few examples of ciphers that utilise RSA key exchange, and therefore should be disabled:

TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Cipher Block Chaining (CBC) Mode

Block ciphers encrypt a fixed-length block of data and therefore to encrypt data of greater length than a single block, a cipher mode must be used. The simplest cipher mode is known as Electronic Cookbook (ECB) and encrypts each piece of the plaintext separately – but this may disclose patterns in the plaintext within the ciphertext, therefore many alternative modes exist that use diffusion to hide these patterns.

For example, with Cipher Block Chaining (CBC), each block of plaintext is XOR-ed with the previous block of ciphertext. The first block is XOR-ed with an initialization vector (IV). However, several padding oracle vulnerabilities have previously been found within implementations of CBC within Transport Layer Security (TLS). Such as Lucky13, Zombie POODLE, and GOLDENDOODLE.

Microsoft has detailed guidance on timing vulnerabilities within CBC-mode ciphers and this has been included in the references below, however, the key detail is:

“Microsoft believes that it’s no longer safe to decrypt data encrypted with the Cipher-Block-Chaining (CBC) mode of symmetric encryption when verifiable padding has been applied without first ensuring the integrity of the ciphertext, except for very specific circumstances.”

Therefore, the use of CBC is now generally discouraged in favour of more secure options such as Galois/Counter Mode (GCM) and Counter with CBC-MAC (CCM).

The following are just a few examples of cipher suites that use CBC mode, and therefore should be disabled:

TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Deprecated Cipher: Triple Data Encryption Standard (3DES or TDEA)

The “Triple Data Encryption Standard” cipher (also known as 3DES or TDEA), was effectively superseded by the Advanced Encryption Standard (AES). Additionally, a birthday attack known as SWEET32 affects multiple ciphers that use 64-bit blocks, which includes 3DES (as well as Blowfish), and was published in late 2016.

Following this, NIST announced they were working on a “draft deprecation timeline” and sunset date for 3DES in 2017. 3DES was formerly disallowed by NIST in 2023. Specifically, within NIST 800-131A Rev 2, NIST states:

“After December 31, 2023, three-key TDEA is disallowed for encryption unless specifically allowed by other NIST guidance.”.

As such, it is recommended that all cipher suites that utilise the 3DES algorithm are disabled. For example, the following:

TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

Deprecated Cipher: Rivest Cipher 4 (RC4)

RC4 is a stream cipher and was deprecated by RFC 7465, released in 2015.

Multiple vulnerabilities have been discovered in RC4, rendering it insecure. There are several known weaknesses in RC4 including statistical biases in the pseudo-random stream that allow an attacker to distinguish RC4 from random and to predict its allegedly pseudo-random bits with high probability.

Additionally, The algorithm RC4 is vulnerable to an attack called Numerous Occurrence Monitoring and Recovery Exploit (NOMORE). Which is a practical attack which has been demonstrated against TLS and allowed for a small amount of ciphertext, such as a session token, to be decrypted within approximately 75 hours.

Given the deprecated status and its known weaknesses, it is recommended that all cipher suites that utilise RC4 are disabled. Including the following examples:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA

Discouraged Ciphers: IDEA, SEED, ARIA, Camellia

RFC 5469, released in 2009, described the IDEA cipher as not having seen “widespread use” and remarked that it was not widely supported. The removal of IDEA due to this lack of use and support is therefore recommended stating, “Experience has shown that rarely used code is a source of security and interoperability problems”.

This same principle may apply to the SEED, ARIA and Camellia algorithms. SEED was developed by the Korean Information Security Agency (KISA) and is used throughout Korean Industry, but rarely used elsewhere. Additionally, some browsers have removed support for SEED, for example Firefox removed SEED in version 27 (released February 2014). ARIA was developed by South Korean researchers and selected by the Korean Agency for Technology and Standards, but is not widely supported by web browsers. Camellia was developed jointly by Mitsubishi Electric and NTT of Japan although is not widely supported by web browsers, for example Firefox removed support in version 33 (released in October 2014).

Therefore, it is recommended that you consider removing these ciphers.

For example:

TLS_RSA_WITH_IDEA_CBC_SHA
TLS_DH_RSA_WITH_SEED_CBC_SHA
TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256

Anonymous Ciphers

Anonymous Ciphers do not utilise X.509 certificates and thereby do not verify the remote server’s identity. This makes connections protected with this cipher type vulnerable to interception. Therefore, it is recommended that these cipher suites are removed. The following are examples of cipher suites that use anonymous ciphers:

TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA

NULL Ciphers

NULL ciphers are a test cipher set which do not offer encryption of data in transit. While this still requires a positioned attacker, with an interception attack it becomes trivial to gain access to data in transit. Therefore, these cipher suites should be removed.

The following are examples of cipher suites using the “NULL” Cipher:

TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_NULL_SHA256

Export Ciphers and the Factoring RSA Export Keys (FREAK) Attack

Export ciphers are a class of ciphers deliberately designed to be weak, as they were produced under pressure of the US Government. This included limiting exportable software from the US to using RSA keys with a moduli of 512 bits (or fewer). This would allow the National Security Agency (NSA) to easily break the encryption if required. However, these days these ciphers can be broken easily by anyone. The attack to break these weak ciphers became known as FREAK.

It is recommended that all export ciphers are disabled. The following are examples of cipher suites that use export grade ciphers:

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5

Weak Diffie-Hellman Exchange

Diffie-Hellman is a key exchange algorithm that can be used with TLS to agree on session keys. A vulnerability in TLS can allow an attacker to downgrade TLS connections to 512-bit export-grade cryptography, which is sufficiently weak that an attacker could break the encryption and access plaintext traffic.

Additionally, many systems use “common primes” with Diffie-Hellman, which leads to the potential for an attacker with significant computing resources to be able to break this protection. However, as computing power increases this will become relatively easier. The original 2015 paper described a 1024-bit common prime group as being breakable by a “nation-state level” attacker, a 768-bit by an “academic team” and breaking 512-bit was demonstrated as taking “several hours on commodity hardware”.