Detecting Post-Quantum TLS: Reading the ServerHello Your Browser Hides

What your browser won't tell you

Open a site over HTTPS and everything looks fine: a padlock, a valid certificate, encrypted traffic. What the browser doesn't surface is how that session was secured — the exact TLS version, the negotiated cipher suite, and, critically, the key-exchange group the two sides agreed on. From ordinary application code, you can't see it either. A fetch() or an HTTP client hands you the response body and headers; the cryptographic handshake parameters were negotiated below that layer and thrown away by the time your code runs.

That blind spot is exactly where the post-quantum question lives. Whether an endpoint offers a hybrid post-quantum key exchange is decided in the handshake — and if you can't read the handshake, you can't audit for it.

Active probing: reading the raw ServerHello

KollGuard's web scanner does an active TLS handshake probe. Instead of just making an HTTPS request, it performs the handshake and reads the raw ServerHello the server sends back. That message is where the server declares the choices it made, so the probe can extract:

• the negotiated TLS version,
• the cipher suite, and
• the key-exchange group.

This is the part you genuinely cannot get from a normal browser or HTTP library — the information isn't exposed by those APIs. You have to speak enough of the protocol to observe the ServerHello directly, which is what the active probe does.

What it flags

With the handshake details in hand, the scanner turns them into findings:

• Legacy TLS. If the endpoint negotiates TLS 1.0 or 1.1, that's flagged. These versions are long deprecated and have no business terminating production traffic.
• Post-quantum key exchange — the novel check. The probe detects whether the endpoint offers a hybrid post-quantum key exchange, such as X25519MLKEM768. This combines a classical curve (X25519) with the ML-KEM post-quantum KEM so a session stays secure even if one of the two is later broken.

Endpoints that don't offer PQC key exchange get a "harvest now, decrypt later" finding — a pointer to the same risk that makes recorded traffic decryptable once quantum computers arrive. It isn't an alarm that you're broken today; it's a flag that this endpoint's key exchange is purely classical and its traffic is a candidate for future retroactive decryption.

Why hybrid, and why the group name matters

The industry's near-term answer to the quantum threat isn't to abandon classical curves — it's to run them alongside a post-quantum KEM in a hybrid. X25519MLKEM768 is the concrete artifact of that decision: X25519 for battle-tested classical security, ML-KEM-768 for quantum resistance. Seeing that group name in the ServerHello is direct, observable evidence that an endpoint has actually deployed post-quantum protection — not a self-reported checkbox, but the wire telling you what happened.

From single endpoint to posture

One endpoint's handshake is a data point; a fleet's handshakes are a posture. Because the scanner reads these parameters actively, the results roll up into the same findings pipeline as the rest of KollGuard — severity, framework mapping, SLA tracking — so a missing post-quantum key exchange is tracked and prioritized like any other gap rather than living in a one-off report.

The practical takeaway is simple: the questions that matter for TLS in a post-quantum world — what version, what cipher, what key exchange, is it hybrid? — are answered in a place your normal tooling can't see. Reading the ServerHello directly is the only way to get an honest answer, and it's what lets an audit distinguish an endpoint that's quantum-ready from one that just looks fine in a browser.