:: [DNG] Fwd: Upcoming compatibility p…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Adrian Zaugg
Date:  
À: dng
Sujet: [DNG] Fwd: Upcoming compatibility problem of oldstable (and older) vs. certificates from Let's Encrypt
Dear List

As far as I can tell, the reported issue on Debian-LTS List is also relevant
for Devuan jessie, ascii and beowulf.

Regards, Adrian.


---------- Forwarded Message ----------

Subject: Upcoming compatibility problem of oldstable (and older) vs.
certificates from Let's Encrypt
Date: Thursday, 9 September 2021, 17:31:49 CEST
From: Stefan Huehner <stefan@???>
To: debian-lts@???
Message-ID: <20210909153149.GF6114@???>

Hello LTS Team,

I want to raise a (rapidly) upcoming compatibility problem affecting older
debian release when connecting via i.e. https:// to any system using SSL
certificates from Let's Encrypt.

Raising here as i didn't see any discussion in debian project.

The problem:
- Starting 2021-10-01
- openssl < 1.1.0
- gnutls < 3.6.14

will fail to validate any Let's Encrypt SSL certificates (which did not do a
per-certificate choice to avoid this).

This article by the project has all the details:
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816

In short:
- They use a certificate chain containing a CA certificate expiring on
2021-10-01
- While that path it not valid after that date, there is alternative path
still being valid
- However older version of some libraries do not even try alternative paths
but give up on seeing the expired one

In Ubuntu they are backporting the chances to avoid this problem in both
openssl / gnutls:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 (openssl)
https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648
(gnutls)

Given the wide-spread use of Let's Encrypt it may make sense to consider doing
that also on the debian side.

Note that apt itself is using gnutls.
So if people are using https:// to access some repos and the repo/mirror uses
Let's Encrypt that could get much more annoying.

Checking openssl / gnutls versions across releases:
jessie        libssl1.0.0        1.0.1t
        libgnutls-deb0-28    3.3.8


stretch        libssl1.0.2        1.0.2u
        libssl1.1        1.1.0l
        libgnutls30        3.5.8


buster        libssl1.0.2        1.0.2u
        libssl1.1        1.1.1d
        libtnutls30        3.6.7


bullseye    libssl1.1        1.1.1k
        libgnutls30        3.7.1


Bug present in
- openssl < 1.1.0
- gnutls < 3.6.14

Looks like:
- bullseye is fine
- But every older release seems to be affected

Assuming there is interest this affects probably
- LTS Team
- ELTS if any of the sponsors is interested
- 'normal' debian for old-stable ?
I just wrote just here for the moment to not spam several teams.

Let's Encrypt offers alternative chain avoiding this bug but breaking
compatibility with old Android. That can server as a workaround for this issue
on case by ase. But as this is on the 'other side' (each certificate) not
really a global fix.

Regards,
Stefan Hühner

p.s. Please CC me on replies, i am not on the list


-----------------------------------------