cURL 7.77 TLS priority string causes TLS downgrade at bitbucket.org #7277
I did this
I expected the following
Retrieving the web page flawlessly. :-)
This is on GNU/Linux, x86_64, with GNU Guix.
As noted in the original bug report, the problem can be reproduced when using the same priority string as cURL with
The priority string looks legit to me though. Are you experiencing this as well?
The text was updated successfully, but these errors were encountered:
I can reproduce with GnuTLS/3.7.1 using current curl from git master.
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
If I remove the
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
This one negotiates and uses TLS 1.3 just fine with the default cipher selection.
Thanks for confirming!
Note that 7.74.0 used a simpler priority string that does not exhibit this problem:
For the record I also notified the
Ah, then the order must be at fault.
If we use the correct order, we get
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?