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-07-19T08:54:31+00:00 jsing 2024-07-19T08:54:31+00:00 urn:sha1:f5a7be1aa230b5dad73001a01843e188c2475c6a SSL_SESSION has a 'ciphers' member which contains a list of ciphers that were advertised by the client. Move this from SSL_SESSION to SSL_HANDSHAKE and rename it to match reality. ok tb@ 2024-06-25T14:10:45+00:00 jsing 2024-06-25T14:10:45+00:00 urn:sha1:dd9ce93fac0548a1fd292d2d756a968f576f40de RSA key exchange is known to have multiple security weaknesses, including being potentially susceptible to padding oracle and timing attacks. The RSA key exchange code that we inherited from OpenSSL was riddled with timing leaks, many of which we fixed (or minimised) early on. However, a number of issues still remained, particularly those related to libcrypto's RSA decryption and padding checks. Rework the RSA key exchange code such that we decrypt with RSA_NO_PADDING and then check the padding ourselves in constant time. In this case, the pre-master secret is of a known length, hence the padding is also a known length based on the size of the RSA key. This makes it easy to implement a check that is much safer than having RSA_private_decrypt() depad for us. Regardless, we still strongly recommend disabling RSA key exchange and using other key exchange methods that provide perfect forward secrecy and do not depend on client generated keys. Thanks to Marcel Maehren, Nurullah Erinola, Robert Merget, Juraj Somorovsky, Joerg Schwenk and Hubert Kario for raising these issues with us at various points in time. ok tb@ 2024-02-03T17:39:17+00:00 tb 2024-02-03T17:39:17+00:00 urn:sha1:252f0ec664690643eb35eed6ce718a990cc29a41 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@