Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Andreas Metzler]

On 2021-01-01 Petter Reinholdtsen  wrote:
> Is there any hope to have a fix for this in unstable soon?  The
> issue block ring and opendht from migrating to testing.

Hello Petter,

3.7.0-5 in unstable features the patch from the yet unmerged
. I would like
to give it more testing in unstable than two non-workdays provide,
though.

> Is this really a RC issue?  I can use https to deb.debian.org and
> some other https mirrors, so the problem seem to trigger only on
> selected mirror sites.  Anyone know of a site currently failing, after
> the debian.ethz.ch one was fixed?
> fixed.

As noted in the upstream bug report this bug is easy to make when using
acme-tiny, so I suspect it to be not that uncommon.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Petter Reinholdtsen]

Is there any hope to have a fix for this in unstable soon?  The
issue block ring and opendht from migrating to testing.

Is this really a RC issue?  I can use https to deb.debian.org and
some other https mirrors, so the problem seem to trigger only on
selected mirror sites.  Anyone know of a site currently failing, after
the debian.ethz.ch one was fixed?
fixed.

-- 
Happy hacking
Petter Reinholdtsen

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Adrian Bunk]

On Sun, Dec 27, 2020 at 12:38:21PM +0100, Julian Andres Klode wrote:
> On Sun, Dec 27, 2020 at 12:25:37PM +0200, Adrian Bunk wrote:
> > On Sun, Dec 27, 2020 at 09:58:06AM +0100, Julian Andres Klode wrote:
> > >...
> > > or revert that madness
> > > of forcing all your reverse depends to depend on gnutls28 just because
> > > there are a few new enum members they _might_ have used - it's doing
> > > more harm then good, and it's not standard practice.
> > 
> > This is actually good practice, if in doubt our dependencies should 
> > always err on the safe side.
> > 
> > Imagine software like apt would have gotten a too low dependency and 
> > then migrated before gnutls to testing.
> > 
> > Or even worse, due to a too low dependency apt would have been upgraded
> > during the first step of an oldstable->stable upgrade, but not gnutls.
> > 
> > In this specific case the higher dependency might not be required for
> > apt specifically, but really bad practice would be risking breakage
> > for our users by not setting the dependency strict enough.
> 
> The tooling is just suboptimal for these cases. I think essentially
> in most cases raising the depends is wrong - if something used newer
> features it would build-depend on newer versions, and run-time depends
> should be max version of (build-depends on dev package, symbols of
> runtime package) or something like it to make this easier to manage,
>...

This cannot work.

It is common for software to autodetect the version or features of a 
library, and use everything that is available at build time.

You cannot build-depend on a not yet available next upstream version of 
a library if your package uses new features from that when it is the
version available at build time.

If in doubt dependencies should be too strict rather than too loose,
what gnutls does here is exactly correct for ensuring that any setup
that fulfills the dependencies is also working.

cu
Adrian

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Julian Andres Klode]

On Sun, Dec 27, 2020 at 12:25:37PM +0200, Adrian Bunk wrote:
> On Sun, Dec 27, 2020 at 09:58:06AM +0100, Julian Andres Klode wrote:
> >...
> > or revert that madness
> > of forcing all your reverse depends to depend on gnutls28 just because
> > there are a few new enum members they _might_ have used - it's doing
> > more harm then good, and it's not standard practice.
> 
> This is actually good practice, if in doubt our dependencies should 
> always err on the safe side.
> 
> Imagine software like apt would have gotten a too low dependency and 
> then migrated before gnutls to testing.
> 
> Or even worse, due to a too low dependency apt would have been upgraded
> during the first step of an oldstable->stable upgrade, but not gnutls.
> 
> In this specific case the higher dependency might not be required for
> apt specifically, but really bad practice would be risking breakage
> for our users by not setting the dependency strict enough.

The tooling is just suboptimal for these cases. I think essentially
in most cases raising the depends is wrong - if something used newer
features it would build-depend on newer versions, and run-time depends
should be max version of (build-depends on dev package, symbols of
runtime package) or something like it to make this easier to manage,
and avoid something with impact similar to a transition.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Adrian Bunk]

On Sun, Dec 27, 2020 at 09:58:06AM +0100, Julian Andres Klode wrote:
>...
> or revert that madness
> of forcing all your reverse depends to depend on gnutls28 just because
> there are a few new enum members they _might_ have used - it's doing
> more harm then good, and it's not standard practice.

This is actually good practice, if in doubt our dependencies should 
always err on the safe side.

Imagine software like apt would have gotten a too low dependency and 
then migrated before gnutls to testing.

Or even worse, due to a too low dependency apt would have been upgraded
during the first step of an oldstable->stable upgrade, but not gnutls.

In this specific case the higher dependency might not be required for
apt specifically, but really bad practice would be risking breakage
for our users by not setting the dependency strict enough.

cu
Adrian

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Julian Andres Klode]

On Tue, Dec 08, 2020 at 01:13:20PM +0100, Jonathan Ballet wrote:
> Package: libgnutls30
> Version: 3.7.0-3
> Severity: critical
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
> I updated gnutls to 3.7.0-3 this morning, then apt was unable to connect to
> the Debian mirror https://debian.ethz.ch/debian/:
> 

> Reverting to libgnutls30 3.6.15-4 seems to fix the problem.


This is a kind reminder that the build-essential freeze is in about
two weeks, and that gnutls28 is a dependency of apt and the questionable
symbol versioning changes together with this release critical bug
prevent it from migrating to testing.

Please get the bug fixed, revert the upload, revert the commit that
introduces the bug, downgrade the bug severity, or revert that madness
of forcing all your reverse depends to depend on gnutls28 just because
there are a few new enum members they _might_ have used - it's doing
more harm then good, and it's not standard practice.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Andreas Metzler]

On 2020-12-08 Axel Beckert  wrote:
> Andreas Metzler wrote:
> > > I updated gnutls to 3.7.0-3 this morning, then apt was unable to connect 
> > > to
> > > the Debian mirror https://debian.ethz.ch/debian/:
> > 
> > > $ sudo apt update
> > > Ign:1 https://debian.ethz.ch/debian sid InRelease
> > > Err:2 https://debian.ethz.ch/debian sid Release
> > >   Certificate verification failed: The certificate is NOT trusted. The 
> > > certificate issuer is unknown.  Could not handshake: Error in the 
> > > certificate verification. [IP: 129.132.53.171 443]
> > > Reading package lists... Done
> [...]
> > afaict the server is misconfigured:

> I beg to disagree. ;-)

Hello Axel,

thanks for following up upstream and providing more context.

My "afaict" was just a result of a quick google for the respective rfc.
I ended up with tls 1.2 (rfc 5246) which has

| The sender's  certificate MUST come first in the list.  Each following
| certificate MUST directly certify the one preceding it.

The current rfc (TLS 1.3 / rfc 8446) is more lenient (MUST -> SHOULD). 
So still the server shouldn't send duplicate certificates.

| Each following certificate SHOULD directly certify the one immediately
| preceding it.
[...]

However according to the rfc GnuTLS should accept the certificate chain.
;-)

| Note: Prior to TLS 1.3, "certificate_list" ordering required each
| certificate to certify the one immediately preceding it; however,
| some implementations allowed some flexibility.  Servers sometimes
| send both a current and deprecated intermediate for transitional
| purposes, and others are simply configured incorrectly, but these
| cases can nonetheless be validated properly.  For maximum
| compatibility, all implementations SHOULD be prepared to handle
| potentially extraneous certificates and arbitrary orderings from any
| TLS version, with the exception of the end-entity certificate which
| MUST be first.

cu Andreas

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Axel Beckert]

Hi Jonathan and Andreas,

Andreas Metzler wrote:
> > I updated gnutls to 3.7.0-3 this morning, then apt was unable to connect to
> > the Debian mirror https://debian.ethz.ch/debian/:
> 
> > $ sudo apt update
> > Ign:1 https://debian.ethz.ch/debian sid InRelease
> > Err:2 https://debian.ethz.ch/debian sid Release
> >   Certificate verification failed: The certificate is NOT trusted. The 
> > certificate issuer is unknown.  Could not handshake: Error in the 
> > certificate verification. [IP: 129.132.53.171 443]
> > Reading package lists... Done
[...]
> afaict the server is misconfigured:

I beg to disagree. ;-)

> The certificate chain sent by the server consists of 3 certificates
> but not each following certificate directly certifies the one
> preceding it.
> - Certificate[1] and Certificate[2] are identical.

Thanks for that hint!

As I already wrote in
https://gitlab.com/gnutls/gnutls/-/issues/1131#note_46246993, this
happens easily when you switch from an earlier version to acme-tiny
4.x and believe that adding the intermediate certificate twice is "not
a big deal, it should still work fine" (or you haven't noticed that
note on upgrading or the upgrade just happened automatically, etc.)...

Anyway, I just fixed that for https://debian.ethz.ch/ (hopefully
permanently — we'll see on next renewal :-) and also verified that the
breakage is indeed there before I manually removed the second
occurence from the certificate file.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Andreas Metzler]

On 2020-12-08 Jonathan Ballet  wrote:
> Package: libgnutls30
> Version: 3.7.0-3
> Severity: critical
> Justification: breaks unrelated software

> Dear Maintainer,

> I updated gnutls to 3.7.0-3 this morning, then apt was unable to connect to
> the Debian mirror https://debian.ethz.ch/debian/:

> $ sudo apt update
> Ign:1 https://debian.ethz.ch/debian sid InRelease
> Err:2 https://debian.ethz.ch/debian sid Release
>   Certificate verification failed: The certificate is NOT trusted. The 
> certificate issuer is unknown.  Could not handshake: Error in the certificate 
> verification. [IP: 129.132.53.171 443]
> Reading package lists... Done
[...]

Hello Jonathan,

afaict the server is misconfigured:

-
(sid)ametzler@argenau:$ gnutls-cli debian.ethz.ch < /dev/null 2>&1 | grep -A1 
'^- Certificate'
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=plattenberg.ethz.ch', issuer `CN=Let's Encrypt Authority 
X3,O=Let's Encrypt,C=US', serial 0x03303e4ec324a9667915ae5fb3383255b202, RSA 
key 4096 bits, signed using RSA-SHA256, activated `2020-11-17 13:03:43 UTC', 
expires `2021-02-15 13:03:43 UTC', 
pin-sha256="7qwNrAIqODvrEwByZ0mAMpm2PROcvYK/BNpYTBzSzfA="
--
- Certificate[1] info:
 - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST 
Root CA X3,O=Digital Signature Trust Co.', serial 
0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, 
activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', 
pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="
- Certificate[2] info:
 - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST 
Root CA X3,O=Digital Signature Trust Co.', serial 
0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, 
activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', 
pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="
-

The certificate chain sent by the server consists of 3 certificates but
not each following certificate directly certifies the one preceding it.
- Certificate[1] and Certificate[2] are identical.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Andreas Metzler]

Control: severity -1 serious

On 2020-12-08 Jonathan Ballet  wrote:
> Package: libgnutls30
> Version: 3.7.0-3
> Severity: critical
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
> I updated gnutls to 3.7.0-3 this morning, then apt was unable to connect to
> the Debian mirror https://debian.ethz.ch/debian/:


Software using gnutls for TLS (namely apt) is not "unrelated", adjusting
severity.

cu Andreas

Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Jonathan Ballet]

Package: libgnutls30
Version: 3.7.0-3
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

I updated gnutls to 3.7.0-3 this morning, then apt was unable to connect to
the Debian mirror https://debian.ethz.ch/debian/:

$ sudo apt update
Ign:1 https://debian.ethz.ch/debian sid InRelease
Err:2 https://debian.ethz.ch/debian sid Release
  Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the certificate 
verification. [IP: 129.132.53.171 443]
Reading package lists... Done
E: The repository 'https://debian.ethz.ch/debian sid Release' no longer has a 
Release file.
N: Updating from such a repository can't be done securely, and is therefore 
disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration 
details.

Using the gnutls client directly gives:

$ gnutls-cli debian.ethz.ch -p 443
Processed 126 CA certificate(s).
Resolving 'debian.ethz.ch:443'...
Connecting to '129.132.53.171:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `CN=plattenberg.ethz.ch', issuer `CN=Let's Encrypt Authority 
X3,O=Let's Encrypt,C=US', serial 0x03303e4ec324a9667915ae5fb3383255b202, RSA 
key 4096 bits, signed using RSA-SHA256, activated `2020-11-17 13:03:43 UTC', 
expires `2021-02-15 13:03:43 UTC', 
pin-sha256="7qwNrAIqODvrEwByZ0mAMpm2PROcvYK/BNpYTBzSzfA="
Public Key ID:
sha1:3c05692d0390a10e4e7cc1a4881c82288b0f6d83
sha256:eeac0dac022a383beb1300726749803299b63d139cbd82bf04da584c1cd2cdf0
Public Key PIN:
pin-sha256:7qwNrAIqODvrEwByZ0mAMpm2PROcvYK/BNpYTBzSzfA=

- Certificate[1] info:
- subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST 
Root CA X3,O=Digital Signature Trust Co.', serial 
0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, 
activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', 
pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="
- Certificate[2] info:
- subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST 
Root CA X3,O=Digital Signature Trust Co.', serial 
0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, 
activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', 
pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="
- Status: The certificate is NOT trusted. The certificate issuer is unknown.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.

Reverting to libgnutls30 3.6.15-4 seems to fix the problem.

Best,

 Jonathan


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgnutls30 depends on:
ii  libc6  2.31-5
ii  libgmp10   2:6.2.1+dfsg-1
ii  libhogweed63.6-2
ii  libidn2-0  2.3.0-4
ii  libnettle8 3.6-2
ii  libp11-kit00.23.21-2
ii  libtasn1-6 4.16.0-2
ii  libunistring2  0.9.10-4

libgnutls30 recommends no packages.

Versions of packages libgnutls30 suggests:
ii  gnutls-bin  3.6.15-4

-- no debconf information