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 , I will only mention that the product line was: Wikipedia 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: Client has a set of configured TLS ciphers. Server also has a set of configured TLS ciphers. 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: The version of TLS. 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 table from author’s Google drive. Please refer to the original one to see deprecated and prohibited ciphers. original It is based on: , August 2008 introduced TLSv1.2 specification (RFC 5246) 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: 8, August 2008 RFC 528 , August 2008 RFC 5289 , March 2009 RFC 5487 , July 2012 RFC 6655 , June 2016 RFC 7905 , August 2016 RFC 7919 , September 2018 RFC 8442 Another important updates are the ones that provide guidance on which ciphers are better to be avoided for security reasons: , February 2015 - prohibits the use of RC4 RFC 7465 - deprecates MD5 and SHA-1 RFC 9155 are not recommended since they do not provide confidentiality and used only for authenticity and integrity purposes null ciphers CBC mode is tend to be , so SSL scanners are likely to flag it as weak vulnerable , August 2018 TLSv1.3 specification (RFC 8446) Unlike its predecessor, TLS 1.3 version has a rather modest number of cipher suites: 5. from September 2023 IANA’s TLS’s Parameters 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 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 that can assist in revealing the ciphers associated with the short notation. Particularly does the magic: commands openssl ciphers -V ‘CIPHER_SUITE‘ If one doesn’t need to manual analyse existing configuration, they can use Mozilla’s 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 on how to use it effectively. awesome tool guide 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 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.