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?
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.
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:
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.
Each TLS version supports only specific ciphers, and not all of them are considered secure.
The general process when configuring TLS involves choosing:
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.
The version of the table presented here is a deflated version of the original table from author’s Google drive. Please refer to the original one to see deprecated and prohibited ciphers.
It is based on:
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:
TLSv1.3 specification (RFC 8446), August 2018
Unlike its predecessor, TLS 1.3 version has a rather modest number of cipher suites: 5.
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.
TLSv1.2 Recommended Ciphers |
TLSv1.3 Recommended Ciphers |
---|---|
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 |
TLS_AES_128_GCM_SHA256 |
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 |
TLS_AES_256_GCM_SHA384 |
TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 |
TLS_CHACHA20_POLY1305_SHA256 |
TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 |
TLS_AES_128_CCM_SHA256 |
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |
|
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
|
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
|
TLS_DHE_RSA_WITH_AES_128_CCM |
|
TLS_DHE_RSA_WITH_AES_256_CCM |
|
TLS_DHE_PSK_WITH_AES_128_CCM |
|
TLS_DHE_PSK_WITH_AES_256_CCM |
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |
|
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 |
|
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |
|
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |
|
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |
|
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 |
|
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 |
|
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 |
|
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:
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.
To dig down into the "Why" and "How" of TLS security, as usually OWASP comes to the rescue.
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
Before implementing a TLS configuration recommendation, it's worth to verify the publication date of the source, whether it's an article or an RFC. This step helps to ensure that the most up-to-date information is used, which is of particular significance when it comes to cryptographic algorithms.
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.