Hardening SSL/TLS: Common SSL Security Issues

Introduction

Secure Sockets Layer (SSL) was a protocol designed to protect network traffic in transit, however it was superseded by Transport Layer Security (TLS) in 1999. These protocols are well-known for protecting web traffic with HTTPS. However, they can be used to protect lots of different kinds of traffic, for example they can also be used to protect email traffic, instant messaging, and more.

Secure Sockets Layer (SSL) and Transport Layer Security (TLS)

The original version of SSL was developed by Netscape for the Navigator browser but was unpublished. Version 2.0 was published in 1995 and updated again to SSL 3.0 in 1996. SSL version 2.0 was prohibited in RFC 6176 released in 2011. SSL version 3.0 was deprecated in RFC 7568 in 2015, which noted the protocol is “comprehensively broken”.

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 in December 2014. Internet Explorer disabled SSL for protected-mode sites in February 2015.

Therefore, all systems these days should exclusively be running Transport Layer Security instead. However, of course this has also had security issues and improvements added over time. TLS 1.0 was first released in 1999, TLS 1.1 was released in 2006, and both were deprecated in 2021. However, many organisations were discouraging the use of “Early TLS” (TLS 1.0) much earlier than the 2021 deprecation date. For example, the Payment Card Industry Security Standards Council (PCI SSC) were pushing organisations to move away from TLS 1.0 before June 2018.

In fact, as TLS 1.0 and TLS 1.1 are now deprecated, many browsers have removed support for these protocols. Chrome deprecated TLS 1.0 and TLS 1.1 in Chrome 72, with a planned removal in Chrome 81. However, this was delayed due to the Coronavirus, although an interstitial warning was added to Chrome 84. TLS 1.2 has been widely supported by web browsers for many years now, for example Chrome has supported the more secure TLS 1.2 since August 2013 and Firefox has supported it since February 2014.

In 2018, TLS 1.3 was released and is widely supported by web browsers, but a lot of sites don’t yet have it enabled, even though it offers security improvements over previous versions.

All of that said, organisations should disable all version of SSL and disable TLS 1.0 and TLS 1.1. You should also check if you have TLS 1.3 enabled, and consider enabling it if you don’t.

Cipher suites

When it comes to configuring TLS there are many more options than just which version your application should support – you also need to configure which “cipher suites” you want to support. These are a set of algorithms used to secure the connection and typically include a key exchange algorithm, an authentication algorithm, a bulk encryption algorithm and an integrity check.

The key exchange algorithm is the algorithm used to exchange keys for use by the bulk encryption algorithm – since you’re potentially communicating with a party you’ve never communicated with before (such as a website you’ve never previously visited) you need some mechanism for exchanging cryptographic keys. This generally involves the use of asymmetric keys to secure a channel by which symmetric keys can be exchanged. Whilst this might seem odd at first, it’s generally due to the fact that symmetric encryption is faster so better suited to “bulk encryption”. An example of an algorithm used for key exchange would be Elliptic-curve Diffie-Hellman. We’ll talk more about that shortly.

The authentication algorithm is used to ensure that the remote server is who it says it is, and as such, an interception attack has not been performed. This leads us into the huge topic of Public Key Infrastructure, in short, your web browser comes preconfigured with the details of a large number of trusted certificate authorities (CA) and your organisation may even have their own CA. The certificate from the remote system is verified to ensure that it is signed by a trusted certificate authority. The idea is that only the correct server could have the correct certificate signed by the trusted third party (the certificate authority) as the CA would not have signed a certificate without first validating the server ownership. I’ve covered certificate and certificate authority issues in another post and so we’ll keep focused on SSL/TLS issues here.

The authentication algorithm may be the same as the key exchange algorithm, for example with TLS_RSA_WITH_AES_256_GCM_SHA384, RSA is used for both key exchange and authentication whereas with TLS_DHE_RSA_WITH_AES_256_CCM, Ephemeral Diffie-Hellman is used for key exchange and RSA is used for authentication. We’ll be diving more into key exchange a little further down.

Additionally note that there is an “Anon” option for authentication, but this effectively disables the authentication check and so it should not be used. For example, in the cipher suite TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384, the authenticity of the remote system is not validated.

The bulk encryption algorithm is the one used to encrypt the bulk of the communications, so the actual web traffic, email traffic, or file download content. We’re using the term bulk encryption algorithm here to distinguish from other encryption algorithms that might be used, for example encryption will be used during key exchange but that algorithm may only be used for key exchange and a different algorithm used for the rest of the data transfer. An example of a bulk encryption algorithm would be AES, again we’ll cover that in more detail shortly.

There is also an integrity check, to ensure that the message came from where it’s supposed to have come from and that it wasn’t tampered with during transit. As encryption is used to mask the contents of a communication (which protects the confidentiality of data) some people assume that this means it also protects the integrity of the data – preventing it from being modified in transit. This isn’t necessarily the case though and the protection of confidentiality and the protection of integrity are two separate challenges and may be handled by different mechanisms. For example, a connection may use AES in CBC-mode for confidentiality but may use a HMAC using SHA-2 for integrity. Alternatively, a system may use AES-GCM which can provide both (AES in Counter Mode for confidentiality and Galios Field arithmetic for integrity checking). We’re not going to go in-depth regarding Hashing Message Authentication Codes (HMAC) and Galois Field arithmetic here, so don’t panic. As long as you understand that confidentiality, integrity, and authentication may be handled by two or more algorithms, or just one very fancy algorithm, that’s enough for now.

Key Exchange Algorithms

The Key Exchange Algorithm is used to exchange a key used for bulk encryption, Key Exchange Algorithm’s typically use asymmetric cryptography for this process.

One of the main concerns here is how the keys are generated and whether it is feasible for an attacker to compromise past sessions when compromising the system. If prior communications are protected, even if the server’s long term secret is compromised, we say the algorithm offers “Forward Secrecy” (FS), or sometimes “Perfect Forward Secrecy” (PFS).

For example, RSA key exchange uses the system’s long term secret (the server’s private key) during key exchange and therefore if the private key is compromised, it’s possible to decrypt prior exchanges. Whereas with Ephemeral Diffie-Hellman Key Exchange, this would not be possible.

Additionally, unique session keys should be generated for each session, meaning that forward secrecy would protect all other communications if a single session key is compromised, as well as protecting prior communications if the long term key is compromised.

One more thing of note here, is the ROBOT attack (That’s Return Of Bleichenbacher’s Oracle Threat) which is a vulnerability in RSA encryption key exchange (or more accurately it’s a padding-oracle attack against PKCS #1 v1.5, used by RSA). This is a significant vulnerability that would allow an attacker to monitor traffic and later decrypt it.

Therefore, due to both ROBOT and its lack of Forward Secrecy in general, you should disable all cipher suites that use RSA encryption key exchange. The IANA name for all of these cipher suites starts “TLS_RSA”, for example TLS_RSA_WITH_AES_128_GCM_SHA256. Not to be confused with cipher suites that use RSA for authentication but not key exchange, such as TLS_DHE_RSA_WITH_AES_256_CCM. You should disable all cipher suites that start TLS_RSA, in favour of more secure alternatives such as Diffie-Hellman Ephemeral (TLS_DHE) or Elliptic Curve Diffie-Hellman Ephemeral (TLS_ECDHE).

Ciphers and Cipher Modes

When it comes to bulk encryption another algorithm may be used and if this is a block cipher, it will also involve the use of a cipher mode. Most encryption algorithms used with TLS are block ciphers and 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 it 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 XORed with the previous block of ciphertext. The first block is XORed with an initialization vector (IV). This hides patterns in the plaintext. 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.

Due to this, the use of both ECB and CBC is discouraged in favour of more secure modes such as CCM and GCM (That’s Counter with Cipher block chaining message authentication code, CCM, and Galois/Counter Mode, GCM, in case you were curious).

To avoid the problem of cipher modes entirely, a block cipher doesn’t have to be used, instead a stream cipher could be used. This would negate the requirement for a cipher mode. Examples of stream ciphers includes Chacha20 and RC4. However, RC4 is known to be vulnerable to attacks such as Bar Mitzvah and RC4NOMORE, so…don’t pick that one.

Other ciphers that are discouraged or deprecated include DES, 3DES, and IDEA. RFC 5469 states the use of DES and IDEA is not recommended (and officially removes them from TLS 1.2, although some implementation may still support them).

DES was superseded by AES in 2002, and officially withdrawn in 2005. Its use in TLS was effectively deprecated in 2009 with RFC 5469 and its removal for TLS 1.2. This RFC released in 2009 described DES as “known to be vulnerable to practical brute force attacks for over 20 years”, whereas it described IDEA as not having seen “widespread use” and remarked that it was not widely supported. It recommended the removal of IDEA due to this lack of use and support 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)

It should be noted here that the other algorithm mentioned above as 3DES has several names, such as Triple Data Encryption Standard (3DES) and Triple Data Encryption Algorithm (TDEA), or simply “Triple DES” but is generally known with TLS as 3DES. This algorithm was deprecated in NIST SP 800-131ar2 and “disallowed after 2023”. Additionally, it has not been included in TLS 1.3.

There are several issues with 3DES, but the most note issue for TLS is likely the “Sweet32” attack, which is a birthday attack against TLS with 64-bit block ciphers.

Finally, there is the option for a “NULL” cipher, which simply means, the traffic should not be encrypted – so this option should definitely not be enabled.

In short, you should disable known deprecated and discouraged ciphers, including DES, IDEA, 3DES, RC2, RC4, IDEA, ARIA, SEED, and NULL ciphers. This may leave you with only AES and ChaCha20, enabled however AES is very widely supported and currently considered to offer a high level of security. Research has shown that ChaCha20 offers a similar level of security to AES but is faster on some CPUs (such as those that do not feature the AES-NI instruction set extension).

Authentication and Integrity Checking

Finally, TLS includes an authentication and integrity check usually via a HMAC, although where possible an AEAD algorithm is preferred (that’s authenticated encryption with associated data, and cipher suites such as TLS_AES_256_GCM_SHA384 utilise this via AES-GCM).

For authentication and integrity checking you may see algorithms such as HMAC-MD5 and HMAC-SHA1 being used and you’ll see a lot of documentation online talking about how MD5 and SHA1 are insecure – and they are, but there’s an important distinction here: Many of the documented attacks against MD5 and SHA1 attack its collision resistance, which is less important in this context as the algorithm is being used as part of a HMAC. This detail is included simply to explain why documents such as NIST SP 800-57p1r5 still mark HMAC-SHA1 as “approved” even though other documents such as NIST SP 800-131Ar2 mark SHA-1 as “disallowed”.

In most practical applications neither no cipher suites that use MD5 or SHA1 should be used in TLS, in part because the cipher suite options that utilise these algorithms are discouraged for other reasons. For example, TLS_RSA_WITH_RC4_128_SHA should be disabled due to its lack of forward secrecy and the use of the broken encryption algorithm RC4. So if you’re grappling with whether HMAC-SHA1 is really that bad – just disable the suite and use something more secure, as you’ll likely be addressing several weaknesses by disabling it.

Summary

TLDR:

• Disable all versions of SSL.
• Disable TLS 1.0 and TLS 1.1, in favour of TLS 1.2 and above.
• Consider enabling TLS 1.3.
• Disable cipher suites that use anonymous authentication.
• Disable key exchange algorithms that do not support forward secrecy, such as RSA, in favour of more secure alternatives such as Diffie-Hellman Ephemeral and Elliptic Curve Diffie-Hellman Ephemeral.
• Disable all known weak, discouraged, and deprecated ciphers, to include at least DES, 3DES, RC2, RC4, and NULL ciphers in favour of more secure algorithms such as AES and ChaCha20.
• Consider disabling cipher suites that use algorithms that are not widely supported, such as IDEA, ARIA, and SEED.
• Disable cipher suites that use weak cipher-modes such as CBC in favour of more secure options such as CCM and GCM.
• Disable weak authentication algorithms such as HMAC-MD5 and HMAC-SHA1 in favour of more secure alternatives such as HMAC-SHA384 or AEAD algorithms such as AES-GCM.

Therefore, if you only require compatibility with modern clients, you should enable only TLS 1.3 with only the following ciphers:

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256

If you require compatibility with legacy clients, such as Windows XP (whose final release was over 15 years ago, whose mainstream support ended in 2009 and whose extended support ended in 2014), or Android 4.4.2 (which was released in January 2014 and is also no longer supported) – then you can add the additional TLS 1.2 cipher suites to the list given above:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA26
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-CHACHA20-POLY1305

Okay, enough sarcasm. The above cipher list when used with TLS 1.2 and TLS 1.3 only offers a decent level of security and with a high level of compatibility. It’s a good middle ground for those who legitimately cannot yet lockdown to TLS 1.3 only and are stuck trying to balance high security with high compatibility.

Configuration

Apache

To configure the above “intermediate” list, include the following within your Apache config:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305

Nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;

Microsoft IIS

Microsoft IIS can be reconfigured via PowerShell which is nice, with the Disable-TlsCipherSuite and Enable-TlsCipherSuite options. The cmdlet Get-TlsCipherSuite can be used to list the supported ciphers (note: this is not the list of currently enabled cipher suites, but in fact the list of cipher suites that may be enabled).

Alternatively, if you prefer a GUI then IISCrypto has a good interface and template options for common configuration requirements.

Cipher suites can be enabled with PowerShell as shown in the example below:

Enable-TlsCipherSuite -Name 'TLS_AES_256_GCM_SHA384'

Unwanted ciphers can be disabled as shown in the example below:

Disable-TlsCipherSuite -Name 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'

References

• Mozilla: Security/Server Side TLS
• ROBOT Attack
• RC4NOMORE
• Bar Mitzvah Attack
• Sweet32
• RFC 5469
• RFC 6176
• RFC 7568
• RFC 8996
• Chrome: Feature: TLS 1.0 and TLS 1.1 (Removed)
• Mozilla: Removing Old Versions of TLS
• Microsoft: Modernizing TLS in Edge/IE11
• Microsoft: Disable-TLSCipherSuites
• Microsoft: Enable-TLSCipherSuites