GNU bug report logs -
#49035
cURL 7.77.0 uses invalid TLS priority string, prevents access to bitbucket.org
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49035 in the body.
You can then email your comments to 49035 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
emmanuel.agullo <at> inria.fr, bug-guix <at> gnu.org
:
bug#49035
; Package
guix
.
(Tue, 15 Jun 2021 09:18:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ludovic Courtès <ludovic.courtes <at> inria.fr>
:
New bug report received and forwarded. Copy sent to
emmanuel.agullo <at> inria.fr, bug-guix <at> gnu.org
.
(Tue, 15 Jun 2021 09:18:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
We came across this problem with the latest Git upgrade, that wasn’t
present in Git 2.31.1 as available on June 1st:
--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=0b76b25a0eff7a422f8ebcc8c095d7ede82c8863 -- environment -CN --ad-hoc git nss-certs -- git clone https://bitbucket.org/oseledets/rectcross /tmp/rectcross
Cloning 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/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
$ 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
--8<---------------cut here---------------end--------------->8---
Thoughts?
Ludo’.
Severity set to 'important' from 'normal'
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Tue, 15 Jun 2021 10:34:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49035
; Package
guix
.
(Tue, 15 Jun 2021 12:40:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 49035 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludovic.courtes <at> inria.fr> skribis:
> $ 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 GnuTLS
3.6.15 → 3.6.16 replacement:
--8<---------------cut here---------------start------------->8---
$ guix environment -CN --no-grafts --ad-hoc git nss-certs -- git clone https://bitbucket.org/oseledets/rectcross /tmp/rectcross
Cloning 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
--8<---------------cut here---------------end--------------->8---
But Git does not use GnuTLS directly, only via cURL:
--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---
And indeed, cURL 7.77 (the replacement) exhibits the bogus behavior:
--8<---------------cut here---------------start------------->8---
$ guix environment -CN --no-grafts --ad-hoc curl <at> 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 <at> 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
--8<---------------cut here---------------end--------------->8---
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49035
; Package
guix
.
(Tue, 15 Jun 2021 21:52:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 49035 <at> debbugs.gnu.org (full text, mbox):
Hi,
(+Cc: gnutls-help; this is about a TLS 1.3→1.2 downgrade at
bitbucket.org, see <https://issues.guix.gnu.org/49035> for context.)
Ludovic Courtès <ludo <at> gnu.org> skribis:
> And indeed, cURL 7.77 (the replacement) exhibits the bogus behavior:
>
> $ guix environment -CN --no-grafts --ad-hoc curl <at> 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 <at> 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’s
the one that cURL 7.77 uses (bad) vs. the one that 7.74 uses (good):
--8<---------------cut here---------------start------------->8---
$ 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.
$ gnutls-cli --priority="NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0" -p https 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.
- 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
--8<---------------cut here---------------end--------------->8---
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?
Aren’t these two priority strings supposed to be equivalent today?
(This is with GnuTLS 3.6.16.)
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49035
; Package
guix
.
(Fri, 18 Jun 2021 12:12:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 49035 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> 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>.
Ludo’.
Changed bug title to 'cURL 7.77.0 uses invalid TLS priority string, prevents access to bitbucket.org' from 'Git 2.32.0 fails with ‘gnutls_handshake’ error'
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 18 Jun 2021 13:02:01 GMT)
Full text and
rfc822 format available.
Reply sent
to
Ludovic Courtès <ludo <at> gnu.org>
:
You have taken responsibility.
(Fri, 18 Jun 2021 15:45:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ludovic Courtès <ludovic.courtes <at> inria.fr>
:
bug acknowledged by developer.
(Fri, 18 Jun 2021 15:45:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 49035-done <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> skribis:
> Ludovic Courtès <ludo <at> 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 specifies
protocol versions in the wrong order, favoring old versions over new
ones (see the issue above).
Fixed in caf4a7a2770ef4d05a6e18f40d602e51da749ddc!
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49035
; Package
guix
.
(Sat, 19 Jun 2021 15:18:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 49035 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> 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
> 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 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 downgrade
protection 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
> 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
Footnotes:
[1] https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3
Regards,
--
Daiki Ueno
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49035
; Package
guix
.
(Sun, 20 Jun 2021 21:27:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 49035 <at> debbugs.gnu.org (full text, mbox):
Hi Daiki,
Daiki Ueno <ueno <at> gnu.org> skribis:
> Ludovic Courtès <ludo <at> 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
[...]
>> 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 cURL
7.77.0 would pass the priority string in the “wrong order”, preferring
older TLS versions. This is now fixed:
https://github.com/curl/curl/issues/7277
Ludo’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 19 Jul 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 304 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.