Detect Split ClientHello failures in TLS 1.3
Split ClientHello failures tend to show up when post-quantum TLS traffic is fragmented and something on the path cannot reassemble it. The connection breaks before the handshake finishes, even though the same host may still work with a classical handshake.
Middleboxes and firewalls are the usual suspects here. If they expect a neat single record and see a split message instead, they may drop or mangle the flow rather than pass it through. That leaves the server looking fine from one angle and broken from another.
Fragmented post-quantum handshakes hit middleboxes first
Post-quantum TLS makes this easier to trigger because the ClientHello can be larger and more awkward on the wire. A split message is not unusual in itself. The failure appears when something in the path cannot cope with the fragmentation and the handshake stalls.
That is the useful signal. If classical TLS connects and the post-quantum path fails, the problem is rarely cryptography. It is usually message handling, path inspection, or some stale assumption in the box in the middle.
What Cloudflare Radar checks for in TLS 1.3 handshake bugs
Cloudflare Radar’s post-quantum TLS support checker tests scanned hosts for handshake bugs and only shows the bugs section when issues are found. The scan results include the bug type and guidance for remediation, which is more useful than a vague pass or fail.
The checker looks for Split ClientHello, HelloRetryRequest failure, and Unknown Keyshare behaviour. Those three cover the awkward parts of TLS 1.3 interoperability where implementations drift away from the specification or fail under a slightly unusual flow.
Split ClientHello, HelloRetryRequest, and unknown keyshare behaviour
Split ClientHello testing sends fragmented post-quantum ClientHello messages and watches for failure. HelloRetryRequest checks whether the handshake still completes after the server asks for another round. Unknown keyshare checks whether the server handles unknown key exchange algorithms in the way TLS 1.3 requires.
The failures are distinct, but they often point to the same sort of weak spot. One host may reject a split message, another may send a HelloRetryRequest and then get stuck, and another may refuse to handle an unknown key exchange at all. Same family of mess, different shape.
The /post_quantum/tls/support endpoint and bug visibility
Bug detection data also appears through the existing /post_quantum/tls/support endpoint. That matters if the web view is not enough and the data needs to be pulled into a monitoring flow or a simple script.
The endpoint gives visibility into the same handshake bugs the Radar checker sees during host scans. For a failing host, that makes it easier to separate “no post-quantum support yet” from “support exists, but this one edge case breaks it”.
Using the scan results to narrow the fault and fix the edge case
The scan result usually tells you where to look first. A Split ClientHello failure points at message handling in the path, not at the certificate or key exchange itself. A HelloRetryRequest failure points at the handshake state machine. An unknown keyshare failure points at TLS 1.3 compliance, which is the sort of thing that tends to lurk in code nobody expected to matter until it did.
The useful fix is rarely broad. For Split ClientHello, inspect middleboxes, firewalls, and any TLS inspection layer that touches fragmented records. For HelloRetryRequest, check that the server completes the retry flow instead of stopping after the first response. For unknown keyshare, check that the implementation follows the TLS 1.3 rule and responds with HelloRetryRequest where required.
That is the whole value of TLS handshake compatibility checks: they turn “it fails somewhere in the handshake” into a specific failure mode with a narrow boundary. Once the bug type is known, the ugly bit is usually already out in the open.
