A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8 2021-09-30T18:26:16+00:00 2021-09-30T18:26:16+00:00 deraadt 2021-09-30T18:26:16+00:00 urn:sha1:93cc8c68508817e38329d627c5154ca849988f6c In order to work around the expired DST Root CA X3 certficiate, enable X509_V_FLAG_TRUSTED_FIRST in the legacy verifier. This means that the default chain provided by Let's Encrypt will stop at the ISRG Root X1 intermediate, rather than following the DST Root CA X3 intermediate. Note that the new verifier does not suffer from this issue, so only a small number of things will hit this code path. ok millert@ robert@ tb@ this is errata 6.8/032_cert.patch 2021-09-26T14:07:09+00:00 deraadt 2021-09-26T14:07:09+00:00 urn:sha1:72c91ffe59378f4b690c1fd772fcbec9722bf30d The length checks need to be >= rather than > in order to ensure the string remains NUL terminated. While here consistently check wi before using it so we have the same idiom throughout this function. Issue reported by GoldBinocle on GitHub. ok deraadt@ tb@ this is 6.8 errata 031 2021-02-03T07:06:14+00:00 tb 2021-02-03T07:06:14+00:00 urn:sha1:5eca2774fbb65f0eac0df1f87aaa91c139b0f724 Various interoperability issues and memory leaks were discovered in libcrypto and libssl. The new verifier is not bug compatible with the old verifier and caused many issues by failing to propagate errors correctly, returning different error codes than some software was trained to expect and otherwise failing when it shouldn't. While much of this is fixed in -current, it's still not perfect, so switching back to the legacy verifier is preferable at this point. Other included fixes: * Unbreak DTLS retransmissions for flights that include a CCS * Only check BIO_should_read() on read and BIO_should_write() on write * Implement autochain for the TLSv1.3 server * Use the legacy verifier for AUTO_CHAIN * Implement exporter for TLSv1.3 * Free alert_data and phh_data in tls13_record_layer_free() * Plug leak in x509_verify_chain_dup() * Free the policy tree in x509_vfy_check_policy() Original commits by jsing and tb ok inoguchi jsing 2020-12-08T15:08:47+00:00 tb 2020-12-08T15:08:47+00:00 urn:sha1:267ac14fa6781b6553b05a6d8dcdf99eaacc0edf Comparing two GENERAL_NAME structures containing an EDIPARTYNAME can lead to a crash. This enables a denial of service attack for an attacker who can control both sides of the comparison. Issue reported to OpenSSL on Nov 9 by David Benjamin. OpenSSL shared the information with us on Dec 1st. Fix from Matt Caswell (OpenSSL) with a few small tweaks. ok jsing this is errata/6.8/008_asn1.patch.sig 2020-09-26T15:44:06+00:00 jsing 2020-09-26T15:44:06+00:00 urn:sha1:4e8347390553060ef9ddb7e486d3c945d2af54ab Previously the leaf certificate was only being set up on the X509_STORE_CTX after two verification steps were performed, however at least one of those steps could result in the verification callback being triggered and existing code breaking. Issue noticed by Raf Czlonka when attempting to connect to talk.google.com using profanity (which does not set SNI and ends up receiving an invalid certificate). ok beck@ deraadt@ tb@ 2020-09-26T02:06:28+00:00 deraadt 2020-09-26T02:06:28+00:00 urn:sha1:3e6655fb0b20e8ae2d4546bab15df8fe320eec75 2020-09-23T18:20:16+00:00 jsing 2020-09-23T18:20:16+00:00 urn:sha1:75f522291d5ee57ddc9fa504c8c61e280dacfbaf Various software expects the previous behaviour where the certificate chain is available on the X509_STORE_CTX when the verify callback is triggered. Issue hit by bket@ with lastpass-cli which has built in certificate pinning that is checked via the verify callback. Fix confirmed by bket@. ok beck@ 2020-09-21T05:41:43+00:00 tb 2020-09-21T05:41:43+00:00 urn:sha1:6ee00092aca7120fdc6c535595cc4d55cda3e05d No change in the generated assembly on amd64. 2020-09-21T05:20:20+00:00 tb 2020-09-21T05:20:20+00:00 urn:sha1:e61b320e8d19af9d30c2c97c456cf47cf857c241 Requested by jsing 2020-09-20T19:13:06+00:00 tb 2020-09-20T19:13:06+00:00 urn:sha1:997a143ecd162f797e525fdea4a0e42c1c73c939 The outer scope in x509_constraints_extract_names() contains a vname variable which will be freed on error, but an inner scope contains another vname that won't be freed, e.g., if x509_constraints_names_add fails. Found by llvm scan-build. ok beck