Skip to content

Post-quantum page

The Post-quantum page in the sidebar checks any server: your origin, an API, a mail server (mail.example.com:587), anything with TLS. It runs the same pqdoctor check as every other report in Flarebox and shows what happened.

The Post-quantum page: a server that isn't post-quantum, the path diagram, and why one level downThe Post-quantum page: a server that isn't post-quantum, the path diagram, and why one level down
The Post-quantum page: a server that isn't post-quantum, the path diagram, and why one level down · Demo mode, sample data

The path diagram at the top of a result shows the request’s journey: visitor → Cloudflare → origin. Browsers already reach Cloudflare over post-quantum TLS. The hop behind it, to your server, is post-quantum only if the server’s TLS library has ML-KEM and its configuration allows it. That hop is what’s coloured by the result: green post-quantum, red classical.

Each result has a handshake diagram: the seven TLS ClientHellos pqdoctor sent, one at a time, and the server’s first reply to each.

The handshake diagram: each probe's offer, key share and the server's reply, coloured by outcomeThe handshake diagram: each probe's offer, key share and the server's reply, coloured by outcome
The handshake diagram: each probe's offer, key share and the server's reply, coloured by outcome · Demo mode, sample data

For every probe it shows:

  • The question it asks, e.g. “Offered ML-KEM first, as browsers do: is it picked?”
  • The ClientHello: the groups offered, the key share sent and its size (an X25519MLKEM768 share is 1,216 bytes; X25519 is 32), and whether it was split across two TCP segments.
  • The reply: a ServerHello with the group picked, a HelloRetryRequest asking for another group, or an alert, a reset or silence.
  • How long the reply took, as a bar against the slowest probe.

Colours: green when the server picked or asked for a post-quantum group, grey for a classical pick, amber when it asked to retry with a classical group, red when there was no handshake at all. Every probe stops at the server’s first reply: no data is sent and no handshake completes.

# Probe What it shows
1 TLS 1.3 with classical groups TLS 1.3 works at all
2 Offer only an X25519MLKEM768 key share The browser case: picked when offered first
3 X25519 share, ML-KEM listed first The server prefers ML-KEM enough to ask for it (pq-preferred)
4 Old draft group X25519Kyber768Draft00 Only the pre-standard draft (kyber-draft-only)
5 PQ ClientHello split across two TCP segments A middlebox drops big hellos split in two (large-hello-dropped)
6 Classical ClientHello, same size, split Whether it’s the size or the codepoint
7 P-256 / P-384 only A hand-set NIST curve list (pinned-nist)

The same diagram is in every report: zone origins, a project’s hosts, and mail servers (under The handshake, probe by probe).

The rest of the result is the full report: why it isn’t post-quantum one level down (config, library or provider, with the evidence), the next step, fixes per stack, the certificate chain and what ML-DSA would do to it, and an openssl s_client command to verify it yourself. See Reading a report.

Recent checks are kept on the page for one click re-checks. To check every origin behind a zone and re-check them daily, use the zone’s Post-quantum tab.