1.3.5 Recommended Suite Configuration
When it comes to cipher suite configuration, the best approach is to avoid legacy keyword-based suite configuration and instead explicitly specify the suites you want to use. By doing this, you don’t have to learn about complex keyword behavior, you’ll minimize mistakes, and you’ll also leave behind a configuration that is self-documenting and easy to understand.
In this section, I will give you my recommendations and explain my reasoning. For simplicity, I’ll show the suites as a single ordered list, even though they are configured separately for TLS 1.3 and separately for earlier protocol versions. Here is my recommended default configuration for all TLS services, given as a list of suites in the order of preference:
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_256_GCM_SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
This configuration uses only suites that support forward secrecy and provide strong encryption.1 The preference is for 128-bit suites, which are faster and provide strong security; ECDSA public key encryption, which is faster and more secure than the traditional RSA (at the usual key lengths); ECDHE key exchange, which is faster than DHE; and authenticated encryption, which is faster and more secure than the old CBC mode.
It’s possible to have a shorter suite configuration—for example, by removing the 256-bit suites, as well as those that use DHE for the key exchange. However, I have found that having a somewhat diverse collection of suites helps avoid various edge cases with picky clients.
In terms of interoperability, all modern browsers and clients should be able to connect. Some very old clients might not, but we’re talking about obsolete platforms—for example, Internet Explorer running on Windows XP. If you really need to support this, you will need to append to the list suites that use obsolete features such as 3DES or the RSA key exchange.
Finally, when it comes to performance, there is one final trick you can employ: tell OpenSSL to use ChaCha20 with clients that prefer this cipher over AES. You will notice that in my configuration, there is always a ChaCha20 suite that follows a 128-bit AES-GCM suite. For most clients, AES-GCM is the right choice, but ChaCha20 is a better option for some mobile clients because they can do it faster.2 With ChaCha20 prioritization, you can give those mobile clients a better experience (faster loading times).
The OpenSSL option for this is called PrioritizeChaCha
. This feature is a relatively new configuration option, and you will find that not all server software can control it. For example, at the time of writing, Apache can (using SSLOpenSSLConfCmd
) but Nginx can’t. Resorting to changing the OpenSSL defaults, as described in the previous section, should do the trick in the latter situation.
In practice, most systems don’t need to be configured to support the best possible performance or mobile client experience. If you enjoy getting your TLS configuration just right, then by all means follow all the advice from this section. Usually, however, you shouldn’t spend too much time on the fine-tuning. If you find yourself with a platform that doesn’t support TLS 1.3 suite configuration or that isn’t able to prioritize ChaCha20, just use the defaults and move on.