Recent releases of various TLS libraries are enabling support for
"post-quantum" key agreement. For example, in OpenSSL 3.5 the default
client behaviour is to send TLS 1.3 "keyshares" for both the hybrid
"post-quantum" X25519MLKEM768 and for the "classical" X25519.
The size of the resulting TLS Client Hello message is close to 1500
bytes and it often splits across multiple TCP segments. This may run
into friction with "middlebox" TLS inspection, or with server TLS stack
implementations, resulting in failure (often timeouts) to complete the
TLS handshake, which hangs or aborts are the TLS Client Hello.
It is expected that use of these algorithms by TLS clients will continue
to grow and it is best to take action now and not wait for problems to
become urgent.
If you have access to a computer with OpenSSL 3.5 (or later) you can
check your server with:
$ host=your.server-fqdn.example
$ (sleep 2; printf 'QUIT\r\n') |
openssl s_client -starttls smtp -connect $host:25 \
-groups "*X25519MLKEM768:*X25519:P-256:ffdhe3072" -state -brief
If this hangs after printing "SSL_connect:SSLv3/TLS write client hello",
you likely have a problem, to confirm, you can try again with:
$ host=your.server-fqdn.example
$ (sleep 2; printf 'QUIT\r\n') |
openssl s_client -starttls smtp -connect $host:25 \
-groups "X25519MLKEM768:*X25519:P-256:ffdhe3072" -state -brief
and if that succeeds promptly, it is appropriate to take action to find
out what's causing the problem, and take steps to remediate it.
--
Viktor. 🇺🇦 Слава Україні!
