openbsd/src, branch OPENBSD_6_7_BASE A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_7_BASE 2020-05-06T15:45:22+00:00 Bump LibreSSL version to 3.1.1 2020-05-06T15:45:22+00:00 tb 2020-05-06T15:45:22+00:00 urn:sha1:ee48f389834876fcbc39c15605a1a3037becc5c2 ok bcook inoguchi deraadt Use a larger (2048 bit) RSA test key. 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. Fix out-of-bounds access in tables[][] that was exposed in bluhm's 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 Accept two ChangeCipherSpec messages during a TLSv1.3 handshake. 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@ Add const to TLS1.3 internal vectors 2020-05-02T00:31:54+00:00 inoguchi 2020-05-02T00:31:54+00:00 urn:sha1:2e6d47dd230cf0a1dc61aea57faf78019cf22858 ok tb@ Disallow setting the AES-GCM IV length to 0 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) tls13_record_layer internal functions to static in libssl 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@ tls13_handshake internal functions to static in libssl 2020-04-29T01:16:49+00:00 inoguchi 2020-04-29T01:16:49+00:00 urn:sha1:45496e817033f7b731f4e6b1bd4022d97015713d ok jsing@ tb@ Move legacy stack interfacing functions into tls13_legacy.c. 2020-04-28T20:37:22+00:00 jsing 2020-04-28T20:37:22+00:00 urn:sha1:5f2791387a6d20d8b8294b1c9ca4e982c7ae6f7e No functional change. ok inoguchi@ tb@ Rename tls13_client_synthetic_handshake_message() and move to tls13_lib.c. 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@