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.

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

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.

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

@civodul does that simpler config make it negotiate 1.3?

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

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

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?

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.

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