From: Theo Buehler <tb@theobuehler.org>
Subject: Re: LibreSSL changes in 7.5?
To: Mischa Peters <openbsd@mlst.nl>
Cc: Tech <tech@openbsd.org>
Date: Sat, 6 Apr 2024 14:23:51 +0200

On Sat, Apr 06, 2024 at 02:11:36PM +0200, Mischa Peters wrote:
> 
> 
> > On 6 Apr 2024, at 13:07, Theo Buehler <tb@theobuehler.org> wrote:
> > 
> > 
> >> -----BEGIN CERTIFICATE-----
> >> MIICPjCCAeSgAwIBAgIJAOy1+v/+I2WIMAoGCCqGSM49BAMCMDkxCzAJBgNVBAYT
> >> Ak5MMRQwEgYDVQQKDAtQaGlsaXBzIEh1ZTEUMBIGA1UEAwwLcm9vdC1icmlkZ2Uw
> >> IhgPMjAxNzAxMDEwMDAwMDBaGA8yMDM4MDExOTAzMTQwN1owPjELMAkGA1UEBhMC
> >> TkwxFDASBgNVBAoMC1BoaWxpcHMgSHVlMRkwFwYDVQQDDBBlY2I1ZmFmZmZlMjM2
> >> NTg4MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEAQMY8V0BUIhXtQfAwMPwqH+2
> >> EyYnNCo9QhpPN93bJIWjppu0DyVUBzXY6rCyMD506mtSN4EsqH/3SHSPKnKD8KOB
> >> yzCByDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggr
> >> BgEFBQcDATAdBgNVHQ4EFgQU1s7ZbOFXYZSJLKhsXrPY072icg4wdAYDVR0jBG0w
> >> a4AUZ2ONTFrDT6o8ItRnKfqWKnHFGmShPaQ7MDkxCzAJBgNVBAYTAk5MMRQwEgYD
> >> VQQKDAtQaGlsaXBzIEh1ZTEUMBIGA1UEAwwLcm9vdC1icmlkZ2WCFDuxUi22sYpL
> >> lwJY81Wrqy11phcOMAoGCCqGSM49BAMCA0gAMEUCIQCdQ2Sfn2t+OBGzDkB59OQO
> >> 6YWwvJ66Q/VZoOyQaCsd3QIgNxpIOEJK3Tk3NTTfCkQOB+vTm285dgGNQ+5Ps3EL
> >> Ni4=
> >> -----END CERTIFICATE-----
> > 
> > This cert is malformed (as is the CA cert that sthen dug up).
> > The notBefore and notAfter are before 2050:
> > 
> > $ openssl x509 -in /tmp/ku.pem -dates -noout
> > notBefore=Jan  1 00:00:00 2017 GMT
> > notAfter=Jan 19 03:14:07 2038 GMT
> > 
> > This means they should be encoded as UTCTime per RFC 5280. However,
> > they are encoded as a GeneralizedTime:
> > 
> > $ openssl asn1parse -i -in /tmp/ku.pem | grep GEN
> >  97:d=3  hl=2 l=  15 prim:    GENERALIZEDTIME   :20170101000000Z
> > 114:d=3  hl=2 l=  15 prim:    GENERALIZEDTIME   :20380119031407Z
> > 
> > The cryptic error is unfortunate. As a consequence of the following
> > commit, x509_verify_cert_info_populate() (which would silently cache
> > nonsense previously) results in EXFLAG_INVALID being set on the cert's
> > extension flags:
> > 
> > https://github.com/openbsd/src/commit/91b40737dd8713c4b24d6504eacee31f6b57e4c1
> > 
> > This in turn leads to an X509_get_key_usage() failure, which in turn
> > leads to ssl_check_srvr_ecc_cert_and_alg() deciding the certificate
> > is not for signing.
> > 
> > Since it is malformed, it is arguably not good for signing. I'm not
> > sure whether 'ftp -S dont' should imply that the cert is completely
> > ignored.
> 
> The fact it’s malformed doesn’t help. :(

I explained what fails and where.

> I am seeing the same with Perl and Net-SSLeay, which was working on 7.4 and no longer on 7.5.
> 
> What would be the best course of action to take with destinations like this? Especially since I can’t control the other side.

I would try this diff first:

Index: ssl_lib.c
===================================================================
RCS file: /cvs/src/lib/libssl/ssl_lib.c,v
diff -u -p -r1.322 ssl_lib.c
--- ssl_lib.c	27 Mar 2024 06:47:52 -0000	1.322
+++ ssl_lib.c	6 Apr 2024 12:23:04 -0000
@@ -2328,7 +2328,7 @@ ssl_check_srvr_ecc_cert_and_alg(SSL *s, 
 
 	alg_a = cs->algorithm_auth;
 
-	if (alg_a & SSL_aECDSA) {
+	if (0 && (alg_a & SSL_aECDSA)) {
 		/* Key usage, if present, must allow signing. */
 		if (!(X509_get_key_usage(x) & X509v3_KU_DIGITAL_SIGNATURE)) {
 			SSLerror(s, SSL_R_ECC_CERT_NOT_FOR_SIGNING);