paint-brush
TLS Cipher Suites: Which Ones to Let Go in 2023?by@mikeaivazovsky
4,139 reads
4,139 reads

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

by mike aivazovskyOctober 23rd, 2023
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

A guide to proper TLS ciphers re-configuration. It will help to remove outdated cipher suites, leaving only those from which the security of the application will benefit.
featured image - TLS Cipher Suites: Which Ones to Let Go in 2023?
mike aivazovsky HackerNoon profile picture


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.

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:

  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:

    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.

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


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:


openssl 3.1.1


  1. 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.


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

  3. To test the cipher suites that the server uses

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.