A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9_BASE 2024-03-26T03:44:11+00:00 2024-03-26T03:44:11+00:00 beck 2024-03-26T03:44:11+00:00 urn:sha1:46faf27986ebd405230bdcdca68dd894ad8635a1 ok jsing@ 2023-04-23T18:51:53+00:00 tb 2023-04-23T18:51:53+00:00 urn:sha1:7af2fcf80381969850949d04fe5368f75e9f7f03 On creation of an SSL using SSL_new(), randomize the order in which the extensions will be sent. There are several constraints: the PSK extension must always come last. The order cannot be randomized on a per-message basis as the strict interpretation of the standard chosen in the CH hashing doesn't allow changing the order between first and second ClientHello. Another constraint is that the current code calls callbacks directly on parsing an extension, which means that the order callbacks are called depends on the order in which the peer sent the extensions. This results in breaking apache-httpd setups using virtual hosts with full ranomization because virtual hosts don't work if the SNI is unknown at the time the ALPN callback is called. So for the time being, we ensure that SNI always precedes ALPN to avoid issues until this issue is fixed. This is based on an idea by David Benjamin https://boringssl-review.googlesource.com/c/boringssl/+/48045 Input & ok jsing 2022-08-04T09:27:36+00:00 tb 2022-08-04T09:27:36+00:00 urn:sha1:5d9686bbd27329b0718190df8e0d8f31e0b7dacc None of these functions are used outside of ssl_tlsext.c. The only reason they are prototyped in the header is for the use of tlsexttest.c. Rather than having a big pile of useless copy-paste in the header, we can adapt the test to avoid using these functions directly. ok jsing 2022-07-20T13:35:05+00:00 tb 2022-07-20T13:35:05+00:00 urn:sha1:c02e9022095ee758d22525cc2a119b410ca01322 The ALPN extension must contain a non-empty list of protocol names. Split a check of this out of tlsext_alpn_server_parse() so that it can be reused elsewhere in the library. ok jsing 2022-06-29T17:39:21+00:00 beck 2022-06-29T17:39:21+00:00 urn:sha1:8c47de5e510352beee68efa6184f2e0085167eec This is the start of adding the boringssl API for QUIC support, and the TLS extensions necessary to send and receive QUIC transport data. Inspired by boringssl's https://boringssl-review.googlesource.com/24464 ok jsing@ tb@ 2022-06-03T13:31:49+00:00 tb 2022-06-03T13:31:49+00:00 urn:sha1:188179007375f728582763efafee0deaa02767fa ok jsing 2022-06-03T13:29:39+00:00 tb 2022-06-03T13:29:39+00:00 urn:sha1:8276aad63c1ae384ddae6bd4771e5dc7f613d8f1 ok jsing 2021-11-01T16:37:17+00:00 jsing 2021-11-01T16:37:17+00:00 urn:sha1:29acda326d204926a29dc59b3fee2491ab5d5b5d For some time now we've validated the hostname provided to the server in the SNI extension. Per RFC 6066, an IP literal is invalid as a hostname - the current code rejects IPv6 literals, but allows IPv4 literals through. Improve this check to explicitly detect both IPv4 and IPv6 literals. Some software has been historically known to include IP literals in SNI, so rather than rejecting this outright (and failing with a decode error), pretend that the SNI extension does not exist (such that we do not break some older clients). ok inoguchi@ tb@ 2020-10-11T01:13:04+00:00 guenther 2020-10-11T01:13:04+00:00 urn:sha1:870191bc3951d25a5d6cffb38ec639299bcd3f10 .data.rel.ro and .rodata respectively. ok tb@ jsing@ 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