A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_7 2020-12-08T15:10:03+00:00 2020-12-08T15:10:03+00:00 tb 2020-12-08T15:10:03+00:00 urn:sha1:374b8d6eac4ffe208e18d32cd2e1cccc7da35e13 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.7/031_asn1.patch.sig 2020-08-17T11:04:20+00:00 tb 2020-08-17T11:04:20+00:00 urn:sha1:4a37c4d3fd4d65240a83ff1723ec253c796045f8 The previous errata patch 019_libssl broke bidirectional SSL_shutdown. This can cause a hang in some software that calls SSL_shutdown in a loop. Problem reported and fix tested by Predrag Punosevac. Thanks to Steffen Nurpmeso who independently found that this was due to an SSL_shutdown loop. ok jsing This is errata/6.7/020_libssl.patch.sig 2020-08-10T18:59:47+00:00 tb 2020-08-10T18:59:47+00:00 urn:sha1:529117a25958fa6a044d9cf79057817756c9e16a * Improve client certificate selection to allow EC certificates instead of only RSA certificates. * Do not error out if a TLSv1.3 server requests an OCSP response as part of a certificate request. * Fix SSL_shutdown behavior to match the legacy stack. The previous behaviour could cause a hang. * Fix a memory leak and add a missing error check in the handling of the key update message. * Fix a memory leak in tls13_record_layer_set_traffic_key. * Avoid calling freezero with a negative size if a server sends a malformed plaintext of all zeroes. * Ensure that only PSS may be used with RSA in TLSv1.3 in order to avoid using PKCS1-based signatures. * Add the P-521 curve to the list of curves supported by default in the client. This is errata/6.7/019_libssl.patch.sig 2020-06-10T03:56:22+00:00 tb 2020-06-10T03:56:22+00:00 urn:sha1:6509152b9d4dd2af6685a777e5384b818cd88911 original commit: CVSROOT: /cvs Module name: src Changes by: jsing@cvs.openbsd.org 2020/05/31 11:23:39 Modified files: lib/libcrypto/x509: x509_vfy.c Log message: When building a chain look for non-expired certificates first. Currently, when building a certificate chain we look up an issuer and if it is the only issuer certificate available we still use it even if it has expired. When X509_V_FLAG_TRUSTED_FIRST is not in use, untrusted certificates are processed first and if one of these happens to be expired it will be used to build the chain, even if there is another non-expired option in the trusted store. Rework this code so that we first look for a non-expired untrusted certificate. If one does not exist then we take a look in the trusted store to see if we would be able to build the chain and only if there is not, do we then look for an expired untrusted certificate. This makes certificate validation possible for various sites that are serving expired AddTrust certificates. Issue reported by Christian Heimes via GitHub. ok beck@ tb@ 2020-05-21T02:27:34+00:00 bcook 2020-05-21T02:27:34+00:00 urn:sha1:98fa86d49f73602179145a8a82817acd8dd42203 2020-05-19T20:22:33+00:00 tb 2020-05-19T20:22:33+00:00 urn:sha1:7b3159529b31e90658d16fd8468765e7ae37f1e5 original commits: CVSROOT: /cvs Module name: src Changes by: jsing@cvs.openbsd.org 2020/05/16 08:44:55 Modified files: lib/libssl : tls13_client.c Log message: Ensure that a TLSv1.3 server has provided a certificate. The RFC requires that a server always provide a certificate for authentication. Ensure that this is the case, rather than proceeding and attempting validation. In the case where validation was disabled and the server returned an empty certificate list, this would have previously resulted in a NULL pointer deference. Issue reported by otto@ ok inoguchi@ tb@ CVSROOT: /cvs Module name: src Changes by: jsing@cvs.openbsd.org 2020/05/17 08:26:15 Modified files: lib/libssl : tls13_client.c Log message: Send a decode error alert if a server provides an empty certificate list. According to RFC 8446 section 4.4.2.4, a client receiving an empty certificate list must abort the handshake with a decode error alert. ok beck@ inoguchi@ tb@ ('it rarely is the alert you'd expect it to be...') 2020-05-06T15:45:22+00:00 tb 2020-05-06T15:45:22+00:00 urn:sha1:ee48f389834876fcbc39c15605a1a3037becc5c2 ok bcook inoguchi deraadt 2020-05-03T15:57:25+00:00 jsing 2020-05-03T15:57:25+00:00 urn:sha1:c011805d37d80a9f55b2f013aa73f0183dff7d25 In compatibility mode, a TLSv1.3 server MUST send a dummy CCS message immediately after its first handshake message. This is normally after the ServerHello message, but it can be after the HelloRetryRequest message. As such we accept one CCS message from the server during the handshake. However, it turns out that in the HelloRetryRequest case, Facebook's fizz TLSv1.3 stack sends CCS messages after both the HelloRetryRequest message and the ServerHello message. This is unexpected and as far as I'm aware, no other TLSv1.3 implementation does this. Unfortunately the RFC is rather ambiguous here, which probably means it is not strictly an RFC violation. Relax the CCS message handling to allow two dummy CCS messages during a TLSv1.3. This makes our TLSv1.3 client work with Facebook Fizz when HRR is triggered. Issue discovered by inoguchi@ and investigated by tb@. ok deraadt@ tb@ 2020-05-02T00:31:54+00:00 inoguchi 2020-05-02T00:31:54+00:00 urn:sha1:2e6d47dd230cf0a1dc61aea57faf78019cf22858 ok tb@ 2020-04-30T18:43:11+00:00 tb 2020-04-30T18:43:11+00:00 urn:sha1:1813a9138ee882b675662d47ed9fe6974bd433f3 It is possible to do this by abusing the EVP_CTRL_INIT API. Pointed out by jsing. ok inoguchi jsing (as part of a larger diff)