A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.1.2 2020-05-19T20:22:33+00:00 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:24+00:00 cvs2svn admin@example.com 2020-05-06T15:45:24+00:00 urn:sha1:8aebf2fb10f113302177f540df5817423bbd2cce 2020-05-06T15:45:22+00:00 tb 2020-05-06T15:45:22+00:00 urn:sha1:ee48f389834876fcbc39c15605a1a3037becc5c2 ok bcook inoguchi deraadt 2020-05-04T16:18:54+00:00 jsing 2020-05-04T16:18:54+00:00 urn:sha1:b2af28cd297d80fb2c19ed05765fb6c5aa610a7a Otherwise we fail to do PSS signatures since the key size is too small. 2020-05-04T14:20:36+00:00 tb 2020-05-04T14:20:36+00:00 urn:sha1:2f51014ac0adf8681f1764313a33eab2c8e9bd11 regress on i386 after inoguchi moved some symbols to const. ok inoguchi jsing 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) 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@