TLSv1.3 bug: server-preferred order detection broken due to Chacha20

[lukastribus]

Hello,

server-preferred order detection fails in TLSv1.3 (# TLS 1.3 (server has no preference)) when the server prefers ChaCha20 suites with clients that don't have AES-NI.

This is haproxy with openssl 1.1.1 (release), prioritizing (OpenSSL's SSL_OP_CIPHER_SERVER_PREFERENCE):

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

With Chacha20 prioritized (OpenSSL's SSL_OP_PRIORITIZE_CHACHA), if the client has it at the top if it's list.

This can easily be reproduced with a openssl command line server:

openssl s_server -port 443 -serverpref -prioritize_chacha

Just because we prioritize Chacha20 when the client doesn't support AES, does not mean there is no server-preference, as can be seen with a simple test, where the clients want's to do AES128, while the server prefers AES256 (just like with real browsers):

$ openssl s_client -connect tls13-test.example.org:443 -servername tls13-test.example.org \
-ciphersuites 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384'
CONNECTED(00000005)
depth=0 CN = tls13-test.example.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = tls13-test.example.org
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:CN = tls13-test.example.org
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=CN = tls13-test.example.org

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1725 bytes and written 398 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: [...]
    Session-ID-ctx:
    Resumption PSK: [...]
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    [...]

    Start Time: 1538338869
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: [...]
    Session-ID-ctx:
    Resumption PSK: [...]
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    [...]

    Start Time: 1538338869
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
^C
$

[felixbuenemann]

I'm also seeing strange behavior, where server-specified cipher preference for TLSv1.3 does not match up with what's reported by ssllabs:

https://dev.ssllabs.com/ssltest/analyze.html?d=ssltest.louis.info&hideResults=on

The report lists TLS 1.3 suites in this order:

1. TLS_AES_256_GCM_SHA384
2. TLS_CHACHA20_POLY1305_SHA256
3. TLS_AES_128_GCM_SHA256

But in NGINX the following is configured:

ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_early_data on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_ciphers "TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA";
ssl_dhparam ssl/ffdhe2048.dhparam;

So the expected cipher order would be:

1. TLS_CHACHA20_POLY1305_SHA256
2. TLS_AES_128_GCM_SHA256
3. TLS_AES_256_GCM_SHA384

However since the client handshakes even with openssl s_client tend to select TLS_AES_256_GCM_SHA384 I think this might be a bug in either nginx 1.15.9 or openssl 1.1.1.

Other TLS versions use the expected cipher preference.

[ArchangeGabriel]

@felixbuenemann For nginx, please read #636.

[Razerwire]

Having the same issue for our site, which if the client has chacha20 on the top of it's list, prefers chacha20:
www.bonnieradvocaten.nl
www.bonnieradvocaten.nl@dev.ssllabs.com

[naumanshah03]

Hi @Razerwire

We've made some changes for detection of Cipher preference and ChaCha preference and deployed the same on dev.ssllabs.com v2.1.2 please run the assessment and verify the same.

Regards,
Nauman Shah

[lukastribus]

Thanks, I can confirm dev works for me now 👍

[naumanshah03]

Hi

Changes are now deployed to production www.ssllabs.com version 2.1.3
We've made changes to API v3, we've added chacha20 preference for the per protocol. Please refer - https://github.com/ssllabs/ssllabs-scan/blob/master/ssllabs-api-docs-v3.md

Regards,
Nauman Shah

[felixbuenemann]

Forgot to post back, but I can confirm this now works as expected. Thanks!

[lilyanatia]

looks like this is still somewhat broken. for a server with the following cipher suite list and SSL_OP_PRIORITIZE_CHACHA:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_AES_128_CCM_SHA256
TLS_CHACHA20_POLY1305_SHA256

SSL Labs indicates that the server does have a preference and prefers ChaCha20 for clients that prefer it, but lists the cipher suites in this incorrect order:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256