Hi folks, Adding a bit more color to the original discussion.
We, at Cloudflare, have been scanning our customer's origin servers [1] for TLS 1.3 key exchange algorithm support. As part of this effort (motivation: measuring post-quantum readiness), we also send empty or unknown keyshare in the Client Hello to force a HelloRetryRequest to learn about origin server keyshare preferences. >From our scanning results, we have seen roughly ~0.32% of them fail to HRR properly (compared to ~0.02% that fail on Split Client Hello due to large keyshares). This small percentage still accounts to thousands of origin servers at our scale, and yes we see HRR incompatibility far more than Split Client Hello bugs/issues. For a bit more context, the server is able to process the first Client Hello and send back a HRR for the updated keyshare. The Client is then able to successfully send a second Client Hello but the origin abruptly closes the TLS connection with a remote "illegal parameter" error. Furthermore, almost 70% of the HRR failure cases seems to be for origins that are being hosted on shared hosting infrastructures (like OVH, Hetzner, DigitalOcean) hence the impact radius is relatively larger. The non-compliant backend servers do not like a second Client Hello coming in on the connection. So far we have seen that HRR incompatibility is NOT related to the choice of keyshare, or whether the first Client Hello fits in a single packet or not. It is simply lack of HRR support. *Side note*: Removing or specifying incorrect SNI, causes the Client Hello to hit a different/default TLS terminating endpoint that supports HRR correctly. When the correct SNI is specified, the responding backend server fails to complete the handshake due HRR failure. Thanks, Suleman [1] https://blog.cloudflare.com/post-quantum-to-origins > ____________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
