A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9 2026-04-03T12:58:19+00:00 2026-04-03T12:58:19+00:00 jsing 2026-04-03T12:58:19+00:00 urn:sha1:42d1ecbb4220b6260fa2da63402ec3f5cbad849a TLS versions prior to TLSv1.2 were disabled a while ago, however this was done in the version handling code. Remove TLSv1.1 and earlier from ssl_get_method() and add an explicit min version check in the legacy client and server, to provide a stronger guarantee. ok kenjiro@ tb@ 2025-12-04T21:03:42+00:00 beck 2025-12-04T21:03:42+00:00 urn:sha1:f8fcf556caab3fb1fb9d9b496d2724345c90a3eb This implements the currently in use MLKEM768_X25519 hybrid key share as outlined in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ This commit does not yet wire this up to anything, that is done in follow on changes. ok tb@ jsing@ kenjiro@ 2025-03-09T15:53:36+00:00 tb 2025-03-09T15:53:36+00:00 urn:sha1:868965d7ddee60d0be2a9a0555eaa25936c7b901 Various ports throw a warning since their tls_session_secret_cb's signature doesn't match what we expect. Aligns us with OpenSSL 1.1. This is only useful for RFC 4851 EAP-FAST implementations and surprisingly it's undocumented. ok jsing 2024-07-22T14:47:15+00:00 jsing 2024-07-22T14:47:15+00:00 urn:sha1:bad64c687dbea7670efcb08ff393fe641d0e673d OpenSSL has had the concept of cipher IDs, which were a way of working around overlapping cipher suite values between SSLv2 and SSLv3. Given that we no longer have to deal with this issue, replace the use of IDs with cipher suite values. In particular, this means that we can stop mapping back and forth between the two, simplifying things considerably. While here, remove the 'valid' member of the SSL_CIPHER. The ssl3_ciphers[] table is no longer mutable, meaning that ciphers cannot be disabled at runtime (and we have `#if 0' if we want to do it at compile time). Clean up the comments and add/update RFC references for cipher suites. ok tb@ 2024-07-20T04:04:23+00:00 jsing 2024-07-20T04:04:23+00:00 urn:sha1:026ea65c83ed46dcfd89ada1f6250daa4fcc01b3 For a long time SSL_SESSION has had both a cipher ID and a pointer to an SSL_CIPHER (and not both are guaranteed to be populated). There is also a pointer to an SSL_CIPHER in the SSL_HANDSHAKE that denotes the cipher being used for this connection. Some code has been using the cipher from SSL_SESSION and some code has been using the cipher from SSL_HANDSHAKE. Remove cipher from SSL_SESSION and use the version in SSL_HANDSHAKE everywhere. If resuming from a session then we need to use the SSL_SESSION cipher ID to set the SSL_HANDSHAKE cipher. And we still need to ensure that we update the cipher ID in the SSL_SESSION whenever the SSL_HANDSHAKE cipher changes (this only occurs in a few places). ok tb@ 2024-07-19T08:56:17+00:00 jsing 2024-07-19T08:56:17+00:00 urn:sha1:bea193397b98da148fada221ab7ddef17f6749cf 2024-02-03T18:03:49+00:00 tb 2024-02-03T18:03:49+00:00 urn:sha1:83d44db7e64e388896b56dd02b9501a0fc40a373 This was used for some GOST weirdness. The flag is unused in ports and there is no user in Debian's codesearch. ok beck 2024-02-03T15:58:34+00:00 beck 2024-02-03T15:58:34+00:00 urn:sha1:20afa90e552d2efed2187dbafc92170a3895e921 This version of GOST is old and not anywhere close to compliant with modern GOST standards. It is also very intrusive in libssl and makes a mess everywhere. Efforts to entice a suitably minded anyone to care about it have been unsuccessful. At this point it is probably best to remove this, and if someone ever showed up who truly needed a working version, it should be a clean implementation from scratch, and have it use something closer to the typical API in libcrypto so it would integrate less painfully here. This removes it from libssl in preparation for it's removal from libcrypto with a future major bump ok tb@ 2023-12-29T12:24:33+00:00 tb 2023-12-29T12:24:33+00:00 urn:sha1:9968234501cfdecd94c72061bdad038b9f340d50 The TLSv1.3 stack didn't support this in the first place, and in the legacy stack it only added some dubious BIO_flush(3) calls. The sleep call between SSL_read(3) and SSL_write(3) advertised in the comment next to the flag has been a sleep call in the s_server since time immemorial, nota bene between calls to BIO_gets(3). Anyway. This can all go and what remains will go with the next major bump. ok jsing 2023-11-19T15:50:29+00:00 tb 2023-11-19T15:50:29+00:00 urn:sha1:0822368d2c2280cffb45de621306b0a04716bb24 This allows us to simplify ssl_do_client_cert_cb() a bit. ok jsing