SNACK: 3-line summary
- Cloudflare has added domain-level TLS key exchange visibility to HTTP Traffic Analytics, Logpush and Log Explorer.
- Site operators can inspect negotiated algorithms and filter visitor traffic by key exchange group.
- Client support still matters, and visitor-to-Cloudflare connections must be checked separately from Cloudflare-to-origin connections.
On September 29, Cloudflare introduced domain-level key exchange visibility in HTTP Traffic Analytics, Logpush and Log Explorer. Site operators can now inspect whether visitor connections actually negotiate a hybrid post-quantum exchange—something the TLS 1.3 label alone cannot confirm.
Snackgirls react
AIKO: I’d like to plot the negotiated groups over time. A TLS 1.3 checkbox doesn’t satisfy my curiosity about which algorithm was actually chosen.
Nea: I’m curious whether a browser and another client would negotiate the same exchange on the same site. If they differed, I’d want to understand what each client supports.
Check the exchange, not just the TLS version
A TLS 1.3 connection can use X25519MLKEM768, which combines shared secrets from classical X25519 and post-quantum ML-KEM. Negotiating that hybrid exchange depends on client support; a connection using TLS 1.3 does not necessarily use it.
In Chrome, open DevTools > Security for the current page to see its key agreement. This describes the connection you are inspecting, not every visitor to the domain or the connection from Cloudflare to your origin server.
Find the TLS Key Exchange card and traffic filter
Select a domain in the Cloudflare Dashboard, go to Analytics > HTTP Traffic, and scroll to the TLS Key Exchange card. It shows the key exchange groups used by visitors connecting to Cloudflare. Those groups are also available as traffic filters, letting you narrow the view to traffic using a particular algorithm.
The announcement’s example includes X25519MLKEM768 alongside classical X25519 and P-256. It also shows None, which can mean RSA key agreement in TLS 1.2 or earlier, or a request without TLS. Do not treat every None entry as unencrypted traffic.
You may also encounter X25519Kyber768Draft00. This is an older, deprecated draft algorithm that Cloudflare is still supporting briefly for compatibility.
Use different log fields for visitors and your origin
For request-level detail, enable ClientTLSKeyExchangeGroup under TLS in the HTTP Requests dataset. It is available in Logpush and Log Explorer and identifies the key exchange used on the visitor-to-Cloudflare connection.
For the Cloudflare-to-origin connection, Logpush exposes the separate OriginTLSKeyExchangeGroup field. Origin connection statistics do not appear in the visitor TLS Key Exchange dashboard card, so use this field to inspect that second connection.
Check client support—and keep authentication separate
If X25519MLKEM768 does not appear, first check SSL/TLS > Edge Certificates > TLS 1.3. Cloudflare has no separate post-quantum setting: when TLS 1.3 is enabled and a visitor supports X25519MLKEM768, the hybrid exchange is negotiated automatically.
Mostly classical traffic may come from non-browser clients that lack TLS 1.3 or hybrid algorithm support. That pattern alone is not evidence of a configuration problem. These new views report existing connections; they are not an encryption upgrade switch.
Post-quantum key exchange protects against the future “harvest now, decrypt later” threat, where encrypted traffic is collected for possible later decryption. Post-quantum authentication and certificate signatures are a separate part of the migration. The new analytics therefore do not establish that every part of a TLS connection is post-quantum ready.
Sources and checked date: Cloudflare · September 30, 2026