A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9 2025-12-04T21:16:17+00:00 2025-12-04T21:16:17+00:00 beck 2025-12-04T21:16:17+00:00 urn:sha1:dccd1f43a0c2de3852d9515f57353d756629c97a This does the following: 1) Adds a second key share prediction to the TLS 1.3 handshake. We only add one as we are unlikely to want to send more than one PQ one, and one classical one and are unlikely to waste bytes on a second PQ algorithm (anything that wants something else that we support can HRR to get it) 2) Adds X25519MLKEM768 (4588) to our list of supported groups. We add this to our preferred client and server key shares for TLS 1.3 and we now have a separate list for TLS 1.2 which does not do this, cleaning up the old "full list" from the comments. 3) Updates the golden magic numbers in the regression tests to allow for the above two things changing the handshake, so the regress tests pass. With this you can successfully hybrid PQ with servers and clients that support it. ok tb@ kenjiro@ 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-10-16T14:42:21+00:00 jsing 2025-10-16T14:42:21+00:00 urn:sha1:07ac085cccf13625ee0512126e736b8da8ed0dad When processing the client supported groups and key shares extensions, the group selection is currently based on client preference. However, when building a HRR the preferred group is identified by calling tls1_get_supported_group(). If SSL_OP_CIPHER_SERVER_PREFERENCE is enabled, group selection will be based on server instead of client preference. This in turn can result in the server sending a HRR for a group that the client has already provided a key share for, violating the RFC. Avoid this issue by storing the client preferred group when processing the key share extension, then using this group when creating the HRR. Thanks to dzwdz for identifying and reporting the issue. ok beck@ tb@ 2025-06-07T10:23:21+00:00 tb 2025-06-07T10:23:21+00:00 urn:sha1:91ab3b327e32cfcdfb3981de527060e4638b8364 ok jsg 2025-04-30T13:50:50+00:00 tb 2025-04-30T13:50:50+00:00 urn:sha1:3276aad9855c6cd2565069523b365fc3fe5df45a All supported releases of LibreSSL ensure that the corresponding callbacks are called in a predefined order rather than honoring the order in which a client sends its extensions. Therefore the ALPN callback for apache-httpd's virtual host setups can rely on SNI information being available and we no longer need to work around this on hte client side. Cuts the amount of code needed for tlsext randomization in half. ok jsing 2024-07-09T12:27:27+00:00 beck 2024-07-09T12:27:27+00:00 urn:sha1:d144661011a28c36d9c8bbce6fa37761e38162ae The check was being too aggressive and was catching us when the extension was being sent by a client which supports tls 1.3 but the server was capped at TLS 1.2. This moves the check after the max version check, so we won't error out if we do not support TLS 1.3 Reported by obsd@bartula.de ok tb@ 2024-06-26T03:41:10+00:00 tb 2024-06-26T03:41:10+00:00 urn:sha1:aad00dc834c7cc402ffc807723f9344ae595b15a ok jsing 2024-06-26T03:39:49+00:00 tb 2024-06-26T03:39:49+00:00 urn:sha1:469e7cab085b04ca8369e8d161c47318845b5970 suggested by jsing 2024-06-25T05:46:48+00:00 tb 2024-06-25T05:46:48+00:00 urn:sha1:16d1647aeb8144aecd31b377e554c6f23fe7912a The diff decoupling the shuffle from the table order still relied on PSK being last because it failed to adjust the upper bound in the for loop. ok jsing 2024-06-06T16:13:12+00:00 tb 2024-06-06T16:13:12+00:00 urn:sha1:29f424547ef436911c355e8cd9af36c19e942a68 This is a false positive but as is well-known, gcc is terrible at understanding conditionally initialized variables and it is tedious to explain this to downstream maintainers who look at warnings. ok miod