TLS Cipher Suites: Which Ones to Let Go in 2023?

In cybersecurity, it is inevitable to face questions like this. Even if one isn't directly related to a security field but is a developer or system administrator, they have probably pondered a similar question when configuring client-server communications.

I am writing this because TLS keeps evolving, gracefully kicking out suites that are no longer considered safe, and I aim to create an article that will save someone time in their investigations. Although investigations can be beneficial for personal growth, I must say.

The main question for today's discussion would be: What cipher suites are appropriate to include in TLS configuration, and which ones should be removed to enhance its security?

The Audience

I am assuming that the reader has intentionally sought out information on TLS cipher suites and found this article. Therefore, I will also assume that the reader is already familiar with concepts related to TLS/SSL, cipher suites, asymmetric and symmetric ciphers, block and stream ciphers, and I won't delve deeply into these topics.

The scenario in which this article is helpful at most is when TLS has been configured for some time, and an individual is considering whether they should revise all the ciphers currently in use.

The Context

TLS is a protocol that defines how communication should occur to achieve a certain level of security. This entails the delivering of packages within the network ensuring that their confidentiality and integrity security aspects were not violated.

The versions history can be found on Wikipedia, I will only mention that the product line was:

SSL 1.0 > SSL 2.0 > SSL 3.0 > TLS 1.0 > TLS 1.1 > TLS 1.2 > TLS 1.3

and each new version is more secure than the previous one.

Typically, one might support older TLS versions for compatibility purposes. However, it is now considered best practice to support versions TLS 1.2 and TLS 1.3 only, and for this article, we will exclusively focus on these two versions.

The TLS process begins with the negotiation, also known as the "Handshake." During this phase, various aspects of the communication are defined. Still, our specific interest lies in the following:

1. Client has a set of configured TLS ciphers.
2. Server also has a set of configured TLS ciphers.
3. When there is a match - information sharing between client and server happens. In cases where multiple matches exist, the most secure cipher is selected. Additionally, there is an option to enable support for a custom priority order of cipher suites if needed.

If, for some reason, the server and client do not have any matching cipher suites, a connection will not be established.

A common example is the communication between a browser and Tomcat web server. Both have configurable predefined cipher suites. If Tomcat's cipher suites have no common ciphers with those set by the browser attempting to establish a connection, it will result in a "Handshake Failed Error."

The concept of a secure TLS configuration, among other settings, involves specifying the permitted cipher suites to prevent any connections from being established using outdated or vulnerable cryptographic algorithms. Moreover, once the initial setup is completed and verified, periodic revisions must be scheduled to ensure correspondence with continually improving security standards.

Straight to the Facts

Each TLS version supports only specific ciphers, and not all of them are considered secure.

The general process when configuring TLS involves choosing:

1. The version of TLS.
2. The ciphers of that version will be supported.

The table below is intended to provide an overview of TLSv1.2 and TLSv1.3, specifying which ciphers are supported and which among them are recommended for use.

It is based on:

1. TLSv1.2 specification (RFC 5246), August 2008 introduced 37 cipher suites.

   This number flows over the internet, claiming “TLS1.2 has 37 ciphers”. To be honest I was quite confused because the list of recommended suites for TLS 1.2 that we can find on IANA’s site has some ciphers that are not in this initial 37-items list. Where did they come from?

   As it turned out, the additional cipher suites beyond the original 37 can be attributed to the release of various RFCs over the years. Some of these RFCs introduced new cipher suites, while others removed older, less secure ones.

   As a result, the joined list of TLS 1.2 ciphers includes at least 111 cipher suites (if I didn’t miss any RFC, although I feel pretty confident about this number) encompassing all of them since the 2008.

   The most crucial updates for this article would be the ones that introduced new cipher suites:

   • RFC 5288, August 2008

   • RFC 5289, August 2008

   • RFC 5487, March 2009

   • RFC 6655, July 2012

   • RFC 7905, June 2016

   • RFC 7919, August 2016

   • RFC 8442, September 2018

   Another important updates are the ones that provide guidance on which ciphers are better to be avoided for security reasons:

   • RFC 7465, February 2015 - prohibits the use of RC4
   • RFC 9155 - deprecates MD5 and SHA-1
   • null ciphers are not recommended since they do not provide confidentiality and used only for authenticity and integrity purposes
   • CBC mode is tend to be vulnerable, so SSL scanners are likely to flag it as weak

2. TLSv1.3 specification (RFC 8446), August 2018

   Unlike its predecessor, TLS 1.3 version has a rather modest number of cipher suites: 5.

3. IANA’s TLS’s Parameters from September 2023

   This paper was updated last month, making it quite current.

   Today's recommendations for the proper configuration of TLS include 24 cipher suites, comprising 20 from TLS 1.2 and 4 from TLS 1.3.

Useful Tools

1. It is common these days to encounter shorter TLS cipher suite notations compared to the classic format. Here are two examples of the same cipher suite described.

   Short Notation:

ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

Classic Notation:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256

OpenSSL provides commands that can assist in revealing the ciphers associated with the short notation. Particularly openssl ciphers -V ‘CIPHER_SUITE‘ does the magic:

2. If one doesn’t need to manual analyse existing configuration, they can use Mozilla’s awesome tool for creating a TLS sample setup. This tool offers a template config that takes into account existing environment and security requirements. They also have a helpful guide on how to use it effectively.

3. To dig down into the "Why" and "How" of TLS security, as usually OWASP comes to the rescue.

   • TLS Cheat Sheet

   • Testing for Weak TLS Ciphers

4. To test the cipher suites that the server uses

   • using web: Qualys SSL Server Test

   • using command line: nmap --script ssl-enum-ciphers -p 443 target-ip

Thanks for reading and happy TLS configuration!

P.S. If you kept asking yourself why Chandler, this is because he knows how to do data reconfiguration.