From: Mischa Subject: Re: LibreSSL changes in 7.5? To: Theo Buehler Cc: Tech Date: Sat, 06 Apr 2024 16:18:51 +0200 On 2024-04-06 14:23, Theo Buehler wrote: > On Sat, Apr 06, 2024 at 02:11:36PM +0200, Mischa Peters wrote: >> >> >> > On 6 Apr 2024, at 13:07, Theo Buehler 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); Thank Theo! Patching against -stable gives me: root@m720q:/usr/src/lib/libssl # patch < /home/mischa/ssl-patch-1.txt Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |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 -------------------------- Patching file ssl_lib.c using Plan A... Hunk #1 failed at 2328. 1 out of 1 hunks failed--saving rejects to ssl_lib.c.rej Hmm... Ignoring the trailing garbage. done I did change the line manually and we have success! root@m720q:~ # ftp https://10.0.0.51/api Trying 10.0.0.51... TLS handshake failure: certificate verification failed: unable to get local issuer certificate root@m720q:~ # ^C root@m720q:~ # ftp -Sdont https://10.0.0.51/api Trying 10.0.0.51... Requesting https://10.0.0.51/api 95 bytes received in 0.00 seconds (279.69 KB/s) Mischa