Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
civodul opened this issue Jun 18, 2021 · 9 comments
Closed

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

civodul opened this issue Jun 18, 2021 · 9 comments
Labels

Comments

@civodul
Copy link

@civodul civodul commented Jun 18, 2021

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 bagder added the SSL/TLS label Jun 18, 2021
@bagder
Copy link
Member

@bagder bagder commented Jun 18, 2021

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
Copy link
Member

@bagder bagder commented Jun 18, 2021

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

@civodul
Copy link
Author

@civodul civodul commented Jun 18, 2021

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
Copy link
Member

@bagder bagder commented Jun 18, 2021

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

@bagder
Copy link
Member

@bagder bagder commented Jun 18, 2021

@civodul does that simpler config make it negotiate 1.3?

@nmav
Copy link
Contributor

@nmav nmav commented Jun 18, 2021

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

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

@civodul
Copy link
Author

@civodul civodul commented Jun 18, 2021

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
Copy link
Member

@bagder bagder commented Jun 18, 2021

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.

bagder added a commit that referenced this issue Jun 18, 2021
Reported-by: civodul on github
Assisted-by: Nikos Mavrogiannopoulos
Fixes #7277
@civodul
Copy link
Author

@civodul civodul commented Jun 18, 2021

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

@bagder bagder closed this in bfa0309 Jun 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants