mirror of
https://github.com/unrealircd/unrealircd.git
synced 2026-06-12 19:14:46 +02:00
Bram Matthys
7b48fdca1a
even if it costs an extra round-trip due to HRR (Hello Retry Request). This is IRC after all, where connections live minutes, hours, days, so that extra round trip is worth it if it means better security. The TL;DR is: we try harder to use X25519MLKEM768. The longer story is as follows: In TLSv1.3, the client will indicate which groups it supports (eg a list of 4 items) and which ones it speculates to be used (very often just 2 items). Some TLS clients may not include X25519MLKEM768 in this initial speculation, but only f.e. X25519 and prime256v1 even though X25519MLKEM768 is communicated via their "supported" list. Without this patch, we would then settle with one of those 2. With this patch, we will send a Hello Retry Request, allowing to use X25519MLKEM768. This is rare, though, most TLS client implementations that have X25519MLKEM768 will bet on it to be used (the 2 they bet on is often X25519MLKEM768 & X25519). That's many browsers like Chrome, OpenSSL, Go, etc. GnuTLS usually will do this as well, but under some configurations it may bet on 2 classic crypto to be used. For that specific (type of) situation, this patch will help to use X25519MLKEM768. This can be tested with OpenSSL to simulate such an implementation: openssl s_client -connect 127.0.0.1:6697 -groups X25519MLKEM768:*X25519 Before this patch, it would result in X25519 (because that is the speculated group, with the asterisk). After this patch it will cause X25519MLKEM768 to be used. The tuple syntax is in 3.5.0+ and our UNREALIRCD_DEFAULT_TLS_GROUPS_PRIMARY with X25519MLKEM768 also requires 3.5.0+ so this is an easy change. Oh and, this commit comment is rather long for a 1 byte change :D