Perfect SSL Labs score with nginx and TLS 1.3?

Question

I have created an nginx config that got a perfect score on Qualsys SSL Labs using only TLS v1.2, and I'd like to try and get a perfect score using both TLS v1.2 and v1.3.

Consider this snippet of the version of the nginx.conf that is part of the A+ and 100% score:

ssl_protocols TLSv1.2;
ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;

It complains about a couple of the cipher suites, but it still gives an otherwise perfect score:

Now, if I add TLS v1.3 to the mix as the only config change, the score changes.

ssl_protocols TLSv1.2 TLSv1.3;

The cipher strength gets scored as a 90%:

I assume it's mad about those weak CBC ciphers:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp384r1 (eq. 7680 bits RSA)   FS   WEAK 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp384r1 (eq. 7680 bits RSA)   FS   WEAK    256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)   DH 4096 bits   FS   WEAK   256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 4096 bits   FS   WEAK

There's not really a good way to remove the CBC mode ciphers perfectly, but maybe excluding SHA1, SHA256, and SHA384 will work. The config line becomes:

ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL:!SHA1:!SHA256:!SHA384;

Let's look at the new score:

The cipher suite strength is still 90%.

It's no longer mad at the strength of the cipher suites:

But apparently it's unhappy about the failing handshakes that worked before:

Which brings us to... the same cipher suites that are required for a successful handshake for older devices/apps are listed as "weak" and pass when only TLS 1.2 is enabled. Somehow enabling TLS 1.3 makes those same weak ciphers that pass before start failing.

It seems like the choice is: either enable TLS 1.2 only to get a perfect score, or, enable TLS 1.3 too but get dinged for the necessary cipher suites? It's a Kobayashi Maru of sorts.

Is it possible to get a perfect 100% score with nginx and TLS 1.2 and 1.3 enabled?

Answer 1

Regarding your actual question, which is about the Qualys SSL Labs test tool itself, we'll have to dig into how their rating system works.
Fortunately Qualys have published their SSL Server Rating Guide, which describes their methodology for rating SSL/TLS configurations.

As your question is about why you got a slightly lower score in the Cipher Strength category with one of your proposed configs over the other, let's focus on that category specifically:

Cipher Strength

To break a communication session, an attacker can attempt to break the symmetric cipher used for the bulk of the communication. A stronger cipher allows for stronger encryption and thus increases the effort needed to break it. Because a server can support ciphers of varying strengths, we arrived at a scoring system that penalizes the use of weak ciphers. To calculate the score for this category, we follow this algorithm:

1. Start with the score of the strongest cipher.
2. Add the score of the weakest cipher.
3. Divide the total by 2.

Table 5. Cipher strength rating guide

Cipher strength               Score
0 bits (no encryption)        0%
< 128 bits (e.g., 40,56)      20%
< 256 bits (e.g., 128, 168)   80%
>= 256 bits (e.g., 256)       100%

Looking back at the more detailed results included in the question, we can see that in the TLS1.2-only config, you were using only 256 bit ciphers (even though some of the cipher suites were frowned upon), while in the TLS1.2+TLS1.3 config you were using a mix of 128 bit and 256 bit ciphers.
Based on their rating system, this explain why you got a reduced score in "Cipher Strength".

Now, this pretty much highlights that while this tool is a very useful resource (particularly to point out actual bad configurations), it's not a great idea to focus too much on the exact scoring, rather to look at the whole report.

As for what is actually a reasonable TLS setup, unless you have a strong idea of what you need, I would suggest looking at the Server Side TLS guidance maintained by Mozilla's Operations Security and Enterprise Information Security teams.
Particularly their "Intermediate" configuration strikes a good balance between broad compatibility and security, and there is a config generator for popular TLS servers for convenient translation of suggested settings into actual server configuration.

Answer 2

It is possible at the cost of TLS1.3 compliance by configuring OpenSSL to exclude some ciphers for TLS 1.3 usage.

I wrote a short howto on it here:

TLS ALL The Things! detailing on how to achieve it plus enable minimum use of 112-bit equivalent for the rest of the OS.

Here you can see the result of the example running here

Note the use of CBC ciphers, normally you want to remove these as well and only run GCM. However, due to the amount of people visiting, you might take that risk instead of forcing everyone to run evergreen. (Go evergreen!)

Anyways, the part you are really interested in is:

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Options = ServerPreference,PrioritizeChaCha

By adding those to your OpenSSL configuration, you will effectively remove the 128 bit parameters... Nginx will still do TLS 1.2 configuration etc for you as that binary controls those settings instead of OpenSSL. The rest of your OS relying on the settings in OpenSSL will thereafter also use these! (warmly recommended)

Answer 3

Same in Apache:

Open console as root and edit /etc/letsencrypt/your-ssl.cnf
SSLEngine on SSLProtocol -all +TLSv1.2 +TLSv1.3 SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-SHA
Open console as root and edit /etc/ssl/openssl.cnf
root@vps# nano /etc/ssl/openssl.cnf
Add this rule in configfile for OpenSSL 1.1.1
CipherSuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Proof: