Hardening cipher suites is one challenge a lot of SysAdmins run into at some point. Complicating the matter, there doesn’t seem to be any firm recommendations on secure cipher suites, or how to order cipher suites for public facing applications. I’ll even bet that before you started researching this topic on your own, you went and asked your Security Team or CISO for their recommendations. I’ll bet they either never responded to your question or found a way to turn the question back to you. How come they’re so good at that? Perhaps you’re the Security Team and you’ve found this page, researching the topic on your own. If so, kudos! You’re one of the good ones.

Part of the challenge with cipher suites is that new encryption technologies emerge over time just like older encryption technologies become deprecated. Furthermore, the vast majority of IT and IT Security practitioners haven’t taken the time to understand TLS or TLS cipher suites in depth. This is understandable, as once configured properly, encryption pretty much just works.

The secondary purpose to this article is to provide some basic foundation on TLS cipher suites, justify my thought process and recommendation, and describe how to configure them in Windows.

Let’s start with some background on Transport Layer Security, or TLS. TLS is the most used protocol for encryption of data in transit today and is implemented on top of the TCP protocol. It’s predecessor, Secure Socket Layer (SSL), is considered insecure and is considered no longer cryptographically sound. That said, many companies still refer to TLS by the name SSL. That said, it is 2022, so take that as a red flag to avoid such companies.

Additionally, both TLS 1.0 and TLS 1.1 also suffer from weaknesses within the protocol and should also no longer be used. This leaves us with TLS 1.2 and TLS 1.3. You should only be using those unless you have some legacy program that requires it. In this case, you might consider leveraging a web application proxy that can offload the TLS connection, so you can provide a TLS 1.2 connection to your users. This will prevent requiring your users’ endpoints to support TLS 1.1 or lower, potentially opening them up to TLS downgrade attacks.

So, what is a cipher suite? Well, those who designed the TLS protocol were very smart and made it future proof, knowing full well that the encryption standards of yesterday may be broken today or tomorrow. The TLS protocol itself does not actually specify the types of encryption to use, but specifies how two parties will negotiate the best way to secure the connection. For a better understanding of the TLS, I’ll refer you to Wikipedia.

In summary, the two parties attempting to establish a TLS connection must agree on the encryption technologies to utilize, or the conversation is doomed to fail. They do this through the use of cipher suites. For a detail breakdown of a cipher suite, I will again refer you to Wikipedia - Cipher Suite but it is good to understand the core components. I prefer the breakdown in NIST SP 800-52r2, as I think it helps to understand the overarching concepts of TLS.

TLS is going to use the KeyExchangeAlg to exchange a secret shared key leveraging as an asymmetric cipher (public/private key pair). The secret key will then be used to encrypt the rest of the conversation using the EncryptionAlg, which will utilize a symmetric cipher. Finally, the MessageAuthenticationAlg describes the hashing mechanism used to ensure the integrity of each message. There are even cipher suites with NULL for some of the components above, so it is possible to be utilizing TLS 1.2 and still be sending your data in plaintext. This sounds crazy, but I’ve nevertheless encountered servers with NULL configured as an accepted encryption algorithm!

Both the client and server must agree on the cipher suite to use. The decision on each end is based on the configured cipher suites supported. When initiating the connection, the client provides a list of support suites and the server selects one, based on its list of supported cipher suites, and the order in which they are configured.

This is a tricky question. As with most areas in security, both physical and informational, it comes down to a decision between risk and convenience. A precursor to any risk assessment is understanding and classifying your data. As a business, you want to support as many of your potential customers as possible. Should this include customers running unsupported operating systems? Securing your ciphers too far may result in incompatibility with older and inherently more insecure devices. This is a decision you’ll have to make.

On the other side, the use of bleeding edge cryptographic mechanisms also comes with some risk. It is important to allow enough time for the world’s leading cryptographers to attempt to crack new ciphers. In general, cryptography that stands up for many years as being secure is what you want to configure in your systems.

The fact that you are visiting this article indicates that you have data that needs to be secured, and that you want to support a vast majority of modern devices. For this, we turn to the National Institute of Standards and Techology (NIST). In 2019, NIST published NIST SP 800-52r2, which describes secure and vetted encryption technologies as of its writing, utilizing recommendations from both NIST and the Federal Information Processing Standard (FIPS). Less than 3 years old (as of this writing), but 5 years since its first draft release, this is still a good age to find modern ciphers that have stood the test of time.