cURL 7.77.0 uses invalid TLS priority string, prevents access to bitbucket.org

DoneSubmitted by Ludovic Courtès.
Details
3 participants
  • Ludovic Courtès
  • Ludovic Courtès
  • Daiki Ueno
Owner
unassigned
Severity
important
L
L
Ludovic Courtès wrote on 15 Jun 11:16 +0200
Git 2.32.0 fails with ‘gnutls_handshake ’ error
(address . bug-guix@gnu.org)
871r93v665.fsf@inria.fr
Hello,
We came across this problem with the latest Git upgrade, that wasn’tpresent in Git 2.31.1 as available on June 1st:
Toggle snippet (20 lines)$ guix time-machine --commit=0b76b25a0eff7a422f8ebcc8c095d7ede82c8863 -- environment -CN --ad-hoc git nss-certs -- git clone https://bitbucket.org/oseledets/rectcross /tmp/rectcrossCloning into '/tmp/rectcross'...Receiving objects: 100% (112/112), 23.43 KiB | 255.00 KiB/s, done.Resolving deltas: 100% (56/56), done.$ rm -rf /tmp/rectcross$ guix time-machine --commit=0b76b25a0eff7a422f8ebcc8c095d7ede82c8863 -- package -A ^git$git 2.31.1 out,send-email,svn,credential-netrc,credential-libsecret,subtree,gui gnu/packages/version-control.scm:176:2$ guix environment -CN --ad-hoc git nss-certs -- git clone https://bitbucket.org/oseledets/rectcross /tmp/rectcrossCloning into '/tmp/rectcross'...fatal: unable to access 'https://bitbucket.org/oseledets/rectcross/': gnutls_handshake() failed: An illegal parameter has been received.$ guix describeGeneracio 185 Jun 07 2021 15:07:46 (nuna) guix e3611cc repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: e3611cc412e7b1c750a56d17fb1b7cde684baa3f$ guix package -A '^git$'git 2.32.0 out,send-email,svn,credential-netrc,credential-libsecret,subtree,gui gnu/packages/version-control.scm:176:2
Thoughts?
Ludo’.
L
L
Ludovic Courtès wrote on 15 Jun 12:33 +0200
control message for bug #49035
(address . control@debbugs.gnu.org)
87wnqvs9hj.fsf@gnu.org
severity 49035 importantquit
L
L
Ludovic Courtès wrote on 15 Jun 14:38 +0200
Re: bug#49035: Git 2.32.0 fails with ‘gnutls_ handshake’ error
(address . 49035@debbugs.gnu.org)(name . Emmanuel Agullo)(address . emmanuel.agullo@inria.fr)
87pmwns3of.fsf@gnu.org
Ludovic Courtès <ludovic.courtes@inria.fr> skribis:
Toggle quote (10 lines)> $ guix environment -CN --ad-hoc git nss-certs -- git clone https://bitbucket.org/oseledets/rectcross/tmp/rectcross> Cloning into '/tmp/rectcross'...> fatal: unable to access 'https://bitbucket.org/oseledets/rectcross/': gnutls_handshake() failed: An illegal parameter has been received.> $ guix describe> Generacio 185 Jun 07 2021 15:07:46 (nuna)> guix e3611cc> repository URL: https://git.savannah.gnu.org/git/guix.git> branch: master> commit: e3611cc412e7b1c750a56d17fb1b7cde684baa3f
Initially I thought this might have to do with the GnuTLS3.6.15 → 3.6.16 replacement:
Toggle snippet (14 lines)$ guix environment -CN --no-grafts --ad-hoc git nss-certs -- git clone https://bitbucket.org/oseledets/rectcross /tmp/rectcrossCloning into '/tmp/rectcross'...Receiving objects: 100% (112/112), 23.43 KiB | 244.00 KiB/s, done.Resolving deltas: 100% (56/56), done.$ guix build gnutls/gnu/store/199npi1hcv7zn0r19vl29np6ccshii4p-gnutls-3.6.16-debug/gnu/store/8ixa3p7hwb26warjinffcrvzl064wbcg-gnutls-3.6.16-doc/gnu/store/akc7l65z459pnifrr6bcm97cjvmpvp9k-gnutls-3.6.16$ guix build gnutls --no-grafts/gnu/store/vswbfgjcadrjlkmd5d7p38rr0i87wdqy-gnutls-3.6.15-debug/gnu/store/fzi1qqvcj5h2b6nsajwlqpf0jb66ngnb-gnutls-3.6.15-doc/gnu/store/5yvzilh78996627i8avq532sl2c03i95-gnutls-3.6.15
But Git does not use GnuTLS directly, only via cURL:
Toggle snippet (6 lines)$ guix graph -t references --path git-minimal $(guix build --no-grafts gnutls |grep '[0-9]$')/gnu/store/skxzvsvnl7yqgx99l0m7mqcpz85l8fml-git-minimal-2.32.0/gnu/store/k9wmrk5m91599lk8gd4rc7h4df642qw0-curl-7.74.0/gnu/store/5yvzilh78996627i8avq532sl2c03i95-gnutls-3.6.15
And indeed, cURL 7.77 (the replacement) exhibits the bogus behavior:
Toggle snippet (11 lines)$ guix environment -CN --no-grafts --ad-hoc curl@7.77 nss-certs -- curl https://bitbucket.org > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (35) gnutls_handshake() failed: An illegal parameter has been received.$ guix environment -CN --no-grafts --ad-hoc curl@7.74 nss-certs -- curl https://bitbucket.org > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed100 75735 100 75735 0 0 134k 0 --:--:-- --:--:-- --:--:-- 134k
Ludo’.
L
L
Ludovic Courtès wrote on 15 Jun 23:51 +0200
TLS downgrade at bitbucket.org
(address . 49035@debbugs.gnu.org)
87eed2re43.fsf_-_@gnu.org
Hi,
(+Cc: gnutls-help; this is about a TLS 1.3→1.2 downgrade atbitbucket.org, see https://issues.guix.gnu.org/49035 for context.)
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (12 lines)> And indeed, cURL 7.77 (the replacement) exhibits the bogus behavior:>> $ guix environment -CN --no-grafts --ad-hoc curl@7.77 nss-certs -- curl https://bitbucket.org > /dev/null> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0> curl: (35) gnutls_handshake() failed: An illegal parameter has been received.> $ guix environment -CN --no-grafts --ad-hoc curl@7.74 nss-certs -- curl https://bitbucket.org > /dev/null> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 100 75735 100 75735 0 0 134k 0 --:--:-- --:--:-- --:--:-- 134k
So these two cURL versions use different TLS priority strings; here’sthe one that cURL 7.77 uses (bad) vs. the one that 7.74 uses (good):
Toggle snippet (32 lines)$ 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.orgProcessed 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.$ gnutls-cli --priority="NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0" -p https bitbucket.orgProcessed 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.- Certificate[0] info: - subject `CN=bitbucket.org,OU=Bitbucket,O=Atlassian\, Inc.,L=San Francisco,ST=California,C=US,serialNumber=3928449,jurisdictionOfIncorporationStateOrProvinceName=Delaware,jurisdictionOfIncorporationCountryName=US,businessCategory=Private Organization', issuer `CN=DigiCert SHA2 Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x040c19f4e9ba36e333316834b8908235, EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2020-03-27 00:00:00 UTC', expires `2022-05-23 12:00:00 UTC', pin-sha256="nFuN2gwclU/9rBe3vz/UUe48hIdL5wLVY8Zke9vApM0=" Public Key ID: sha1:5f7c6de5e52a6bc39dfdcd5230220f1a7957772b sha256:9c5b8dda0c1c954ffdac17b7bf3fd451ee3c84874be702d563c6647bdbc0a4cd Public Key PIN: pin-sha256:nFuN2gwclU/9rBe3vz/UUe48hIdL5wLVY8Zke9vApM0=
- Certificate[1] info: - subject `CN=DigiCert SHA2 Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US', issuer `CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x0c79a944b08c11952092615fe26b1d83, RSA key 2048 bits, signed using RSA-SHA256, activated `2013-10-22 12:00:00 UTC', expires `2028-10-22 12:00:00 UTC', pin-sha256="RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho="- Status: The certificate is trusted. - Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-128-GCM)- Options: OCSP status request,- Handshake was completed
- Simple Client Mode:
C-c C-c
The key thing here is “Detected downgrade to TLS 1.2 from TLS 1.3”.
Why is a downgrade detected when using the most explicit prioritystring and not when using the shorter string?
Aren’t these two priority strings supposed to be equivalent today?
(This is with GnuTLS 3.6.16.)
Thanks,Ludo’.
L
L
Ludovic Courtès wrote on 18 Jun 14:10 +0200
Re: bug#49035: Git 2.32.0 fails with ‘gnutls_ handshake’ error
(address . 49035@debbugs.gnu.org)(name . Emmanuel Agullo)(address . emmanuel.agullo@inria.fr)
87wnqrfk4t.fsf_-_@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (3 lines)> So these two cURL versions use different TLS priority strings; here’s> the one that cURL 7.77 uses (bad) vs. the one that 7.74 uses (good):
L
L
Ludovic Courtès wrote on 18 Jun 15:01 +0200
control message for bug #49035
(address . control@debbugs.gnu.org)
874kdvfhsr.fsf@gnu.org
retitle 49035 cURL 7.77.0 uses invalid TLS priority string, prevents access to bitbucket.orgquit
L
L
Ludovic Courtès wrote on 18 Jun 17:43 +0200
Re: bug#49035: Git 2.32.0 fails with ‘gnutls_ handshake’ error
(address . 49035-done@debbugs.gnu.org)(name . Emmanuel Agullo)(address . emmanuel.agullo@inria.fr)
87y2b7dvpd.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (7 lines)> Ludovic Courtès <ludo@gnu.org> skribis:>>> So these two cURL versions use different TLS priority strings; here’s>> the one that cURL 7.77 uses (bad) vs. the one that 7.74 uses (good):>> Also reported at <https://github.com/curl/curl/issues/7277>.
The issue turned out to be that cURL’s priority string specifiesprotocol versions in the wrong order, favoring old versions over newones (see the issue above).
Fixed in caf4a7a2770ef4d05a6e18f40d602e51da749ddc!
Thanks,Ludo’.
Closed
D
D
Daiki Ueno wrote on 19 Jun 17:17 +0200
Re: [gnutls-help] TLS downgrade at bitbucket.org
(name . Ludovic Courtès)(address . ludo@gnu.org)
87tultyjcl.fsf-ueno@gnu.org
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (7 lines)> $ 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.
[...]
Toggle quote (5 lines)> The key thing here is “Detected downgrade to TLS 1.2 from TLS 1.3”.>> Why is a downgrade detected when using the most explicit priority> string and not when using the shorter string?
I would say this is an expected behavior when the TLS downgradeprotection mechanism[1] is in action. What happens is as follows:
- the client advertises TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 (in this order) in the supported_versions extension
- the server skips TLS 1.0 and TLS 1.1 (maybe it's disabled), sees TLS 1.2 first in supported_versions, then TLS 1.3; while it also supports TLS 1.3, as TLS 1.2 has precedence and it selects TLS 1.2 and sends the downgrade sentinel in server_random
- the client sees the sentinel while TLS 1.3 is enabled, treats it as an unwanted protocol downgrade
Toggle quote (2 lines)> Aren’t these two priority strings supposed to be equivalent today?
No. If -VERS-TLS-ALL is used, the default priorities on TLS versions inNORMAL are ignored; the user is responsible for building the prioritystring so it reflects the actual preference, which in this case is:
-VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0
Footnotes:[1] https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3
Regards,-- Daiki Ueno
L
L
Ludovic Courtès wrote on 20 Jun 23:26 +0200
(name . Daiki Ueno)(address . ueno@gnu.org)
87wnqo6xe2.fsf@gnu.org
Hi Daiki,
Daiki Ueno <ueno@gnu.org> skribis:
Toggle quote (4 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> $ 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
[...]
Toggle quote (8 lines)>> Aren’t these two priority strings supposed to be equivalent today?>> No. If -VERS-TLS-ALL is used, the default priorities on TLS versions in> NORMAL are ignored; the user is responsible for building the priority> string so it reflects the actual preference, which in this case is:>> -VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0
Thanks for the explanations. As you suggest, the mistake was that cURL7.77.0 would pass the priority string in the “wrong order”, preferringolder TLS versions. This is now fixed:
https://github.com/curl/curl/issues/7277
Ludo’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 49035@debbugs.gnu.org