openbsd/src/lib, 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 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@ Shuffle some functions around. 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@ Disallow the use of zero length IVs in AES-GCM via 2020-04-27T19:31:02+00:00 tb 2020-04-27T19:31:02+00:00 urn:sha1:59b4077b60cc24004bc23295bd2ff465be743f11 EVP_AEAD_CTX_{open,seal}, as this leaks the authentication key. Issue reported and fix tested by Guido Vranken. ok beck, jsing This commit adds a constant to a public header despite library lock, as discussed with deraadt and sthen.