cURL 7.77 TLS priority string causes TLS downgrade at bitbucket.org

[civodul]

I did this

$ curl https://bitbucket.org
curl: (35) gnutls_handshake() failed: An illegal parameter has been received.

I expected the following

Retrieving the web page flawlessly. :-)

curl/libcurl version

$ curl --version
curl 7.77.0 (x86_64-unknown-linux-gnu) libcurl/7.77.0 GnuTLS/3.6.16 zlib/1.2.11 libidn2/2.3.0 nghttp2/1.41.0 OpenLDAP/2.4.57
Release-Date: 2021-05-26
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB SPNEGO SSL TLS-SRP UnixSockets
$ ldd $(type -P curl) |grep gnutls
        libgnutls.so.30 => /gnu/store/akc7l65z459pnifrr6bcm97cjvmpvp9k-gnutls-3.6.16/lib/libgnutl.so.30 (0x00007f7710cb2000)

operating system

This is on GNU/Linux, x86_64, with GNU Guix.

further info

As noted in the original bug report, the problem can be reproduced when using the same priority string as cURL with gnutls-cli:

$ gnutls-cli --priority="NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-TLS1.1:+VERS-TLS1.2:+VERS-TLS1.3" -p https bitbucket.org
Processed 444 CA certificate(s).
Resolving 'bitbucket.org:https'...
Connecting to '2406:da00:ff00::6b17:d1f5:443'...
|<1>| Detected downgrade to TLS 1.2 from TLS 1.3
*** Fatal error: An illegal parameter has been received.

The priority string looks legit to me though. Are you experiencing this as well?

Thoughts?

[bagder]

I can reproduce with GnuTLS/3.7.1 using current curl from git master.

fails

Default build, uses this prioritylist: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-TLS1.1:+VERS-TLS1.2:+VERS-TLS1.3

./src/curl https://bitbucket.org -v -o /dev/null

If I remove the +VERS-TLS1.3 string from the "prioritylist", it works. But I cannot understand why GnuTLS insists I do that when TLS 1.3 is working in this version.

Using NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-TLS1.1:+VERS-TLS1.2

Then curl/GnuTLS will negotiate TLS1.2 / ECDHE_ECDSA_AES_128_GCM_SHA256.

If I instead use curl/openssl against this site it negotiates TLSv1.3 / TLS_AES_128_GCM_SHA256

works

./src/curl https://github.com/ -v -o /dev/null

This one negotiates and uses TLS 1.3 just fine with the default cipher selection.

[bagder]

@nmav, do you have any clues on this for us?

[civodul]

Thanks for confirming!

Note that 7.74.0 used a simpler priority string that does not exhibit this problem: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0. One possibility would be to revert back to that string, which, AIUI, should be equivalent to the more complex priority string used in 7.77.0.

For the record I also notified the gnutls-help mailing list as this might be a GnuTLS bug but haven't heard from them yet.

[bagder]

Yeah, this is probably a regression introduced with #7000 (and the followup #7014)

[bagder]

@civodul does that simpler config make it negotiate 1.3?

[nmav]

@nmav, do you have any clues on this for us?

Order matters, you are prioritizing the older protocols over TLS1.3.

[civodul]

Ah, then the order must be at fault.

If we use the correct order, we get -VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0, which fixes the problem:

$ gnutls-cli -p https --priority=NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0 bitbucket.org
Processed 444 CA certificate(s).
Resolving 'bitbucket.org:https'...
Connecting to '2406:da00:ff00::6b17:d1f5:443'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
[...]
- Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-128-GCM)
- Options: OCSP status request,
- Handshake was completed

However, isn't this equivalent to nothing (empty string), @nmav, at least until TLS 1.4 comes into existence?

In other word, is there value in being explicit?

[bagder]

I figure if we're fine with 1.0 to 1.3, then using NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0 seems to do it.

[civodul]

I confirm that this patch fixes the problem. Thanks @bagder for the quick response!