openbsd/src/lib/libssl/ssl_tlsext.c, branch OPENBSD_6_8_BASE A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE 2020-09-09T12:31:23+00:00 Set alpn_selected_len = 0 when alpn_selected is NULL 2020-09-09T12:31:23+00:00 inoguchi 2020-09-09T12:31:23+00:00 urn:sha1:7f18b549cb1b4471f10e8f40eeae96a572c264f9 ok jsing@ tb@ Only parse a client's status_request in the CH 2020-08-03T19:46:55+00:00 tb 2020-08-03T19:46:55+00:00 urn:sha1:5ab44d4a02a115699195e9833f705215d34b4447 A client should only send a status_request as part of the CH. Pointed out by Michael Forney ok inoguchi jsing Ensure clients only send a status_request in the CH 2020-08-03T19:43:16+00:00 tb 2020-08-03T19:43:16+00:00 urn:sha1:6528ebc99874356c505de8b798aad974aaccec93 The current code might cause a client to send a status_request containing a CertificateStatusRequest with its certificate. This makes no sense. Pointed out by Michael Forney ok inoguchi jsing Correctly handle server requests for an OCSP response 2020-08-03T19:27:57+00:00 tb 2020-08-03T19:27:57+00:00 urn:sha1:2a08260cd485b4464ce53ee7fd671c11c7946044 According to RFC 8446, 4.4.2.1, a server may request that a client present an OCSP response with its certificate by sending an empty status_request extension as part of the certificate request. The current code expects a full CertificateStatus structure, which is only sent if the server sends an OCSP response with its certificate. This causes interoperability issues with Go's TLS server and with newer GnuTLS where we would abort the handshake with a decode_error alert and length mismatch error. Issue reported and diagnosed by Michael Forney Problem also found by Mikolaj Kucharski and inoguchi. ok inoguchi jsing zap trailing whitespace on one line 2020-07-03T07:17:26+00:00 tb 2020-07-03T07:17:26+00:00 urn:sha1:0cc196069e4836a1116df5183cceb61563ee171b Make the message type available to the extension functions 2020-07-03T04:51:59+00:00 tb 2020-07-03T04:51:59+00:00 urn:sha1:0bfb0ca4cf5c93e1c9f105fdbdcd8825c432e4f1 Some TLS extensions need to be treated differently depending on the handshake message they appear in. Over time, various workarounds and hacks were used to deal with the unavailability of the message type in these functions, but this is getting fragile and unwieldy. Having the message type available will enable us to clean this code up and will allow simple fixes for a number of bugs in our handling of the status_request extension reported by Michael Forney. This approach was suggested a while ago by jsing. ok beck jsing Improve argument order for the internal tlsext API 2020-07-03T04:12:51+00:00 tb 2020-07-03T04:12:51+00:00 urn:sha1:3634005e8a2051a239211f692a45371c14e9d8e4 Move is_server and msg_type right after the SSL object so that CBS and CBB and alert come last. This brings these functions more in line with other internal functions and separates state from data. requested by jsing Implement a rolling hash of the ClientHello message, Enforce RFC 8446 2020-06-06T01:40:09+00:00 beck 2020-06-06T01:40:09+00:00 urn:sha1:2d835ca8318d9ce502e9fd2dced3ef440decb39d section 4.1.2 to ensure subsequent ClientHello messages after a HelloRetryRequest messages must be unchanged from the initial ClientHello. ok tb@ jsing@ Mop up servername_done, which is unused. 2020-05-29T17:39:42+00:00 jsing 2020-05-29T17:39:42+00:00 urn:sha1:0fa647cafcb45ea07c768d172165a3a041e8c58f ok beck@ inoguchi@ tb@ Fix some stylistic nits from jsing. 2020-05-24T15:13:22+00:00 tb 2020-05-24T15:13:22+00:00 urn:sha1:e198bb3ccaa2a2cff7965f20f3e1e296b66f1be0 ok jsing