A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.1.5 2020-08-17T11:04:20+00:00 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-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-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-29T01:22:28+00:00 inoguchi 2020-04-29T01:22:28+00:00 urn:sha1:cbd0a539eed34c8b6b65717c68d01a47aa9aa314 We might remove static again for further regress around record layer in the future. ok jsing@ tb@ 2020-04-29T01:16:49+00:00 inoguchi 2020-04-29T01:16:49+00:00 urn:sha1:45496e817033f7b731f4e6b1bd4022d97015713d ok jsing@ tb@ 2020-04-28T20:37:22+00:00 jsing 2020-04-28T20:37:22+00:00 urn:sha1:5f2791387a6d20d8b8294b1c9ca4e982c7ae6f7e No functional change. ok inoguchi@ tb@ 2020-04-28T20:30:41+00:00 jsing 2020-04-28T20:30:41+00:00 urn:sha1:d1fef479fc505086d5703546f04121c5c2c8c507 The server-side will need to use the same function. No functional change. ok inoguchi@ tb@ 2020-04-27T20:15:17+00:00 jsing 2020-04-27T20:15:17+00:00 urn:sha1:e59cdf2c749347a4acc7576297f18cebeee7d37d Move functions so that they are in the order that the TLSv1.3 messages are processed. While here, also move tls13_client_end_of_early_data_send() from tls13_client.c to tls13_server.c. No functional change. ok beck@ tb@