summaryrefslogtreecommitdiff
path: root/src/lib/libssl/pqueue.h
diff options
context:
space:
mode:
authortb <>2026-06-06 08:45:41 +0000
committertb <>2026-06-06 08:45:41 +0000
commit93c5a7dd0add95919ba07556309ed8db9d396005 (patch)
treea470598d3597d847e54629eaedfd8a48342bddeb /src/lib/libssl/pqueue.h
parent959cf9ab5ba19116c52ad633faab70292d4c6858 (diff)
downloadopenbsd-93c5a7dd0add95919ba07556309ed8db9d396005.tar.gz
openbsd-93c5a7dd0add95919ba07556309ed8db9d396005.tar.bz2
openbsd-93c5a7dd0add95919ba07556309ed8db9d396005.zip
libssl: don't break TLSv1.2 with X25519MLKEM768
If the list of 'groups' starts with X25519MLKEM768 for a TLSv1.2 server, ssl3_send_server_kex_ecdhe() attempts to use NID_X25519MLKEM768, which it receives from tls1_get_supported_groups(). This does not work because it never received the peer's public keys, which causes an error return from tls_key_share_server_generate_mlkem768x25519(). For a TLSv1.2-only client with custom supported group list we will currently send ML-KEM if configured. We should not do this. There is more to fix here: if a TLSv1.2 client is misconfigured with only X25519MLKEM768, we should not send a supported groups extension (with this commit we'll send an empty one, which is an RFC violation). This commit simply filters X25519MLKEM768 out of the supported groups list if we're configured to be TLSv1.2-only. feedback/ok jsing kenjiro (on an earlier version)
Diffstat (limited to 'src/lib/libssl/pqueue.h')
0 files changed, 0 insertions, 0 deletions