Skip to cookie settingsSkip to content
Back to the blog

Is post-quantum key exchange still on after your last CDN change?

A CDN change can turn off post-quantum key exchange while your pages keep loading without a warning. Browsers fall back to classical key exchange when the new setup doesn't offer hybrid groups.

Chrome, Edge, Firefox, and Safari now offer post-quantum key exchange by default.

Key exchange happens wherever Transport Layer Security (TLS) ends: your CDN, load balancer, or proxy. Each runs its own TLS software with its own defaults. Moving traffic can change which key exchange your visitors use.

Hybrid key exchange guards against harvest now, decrypt later: traffic recorded today and opened once a large enough quantum computer exists.

We track changes like this because pages loading as before doesn't tell you whether a security setting survived.

What we check

Our post-quantum cryptography (PQC) check tests whether an endpoint completes a handshake with an RFC 10024 hybrid group. It also tests whether the endpoint picks a hybrid group when offered hybrid and classical groups together.

When a CDN change removes hybrid support, we record "Post-quantum key exchange support removed". A default monitor alerts because Supports post-quantum key exchange and Prefers post-quantum key exchange break. Alerts only cover assertions you've ticked.

A server can also keep hybrid support and stop preferring it. Then only Prefers post-quantum key exchange breaks, and the change reads "Preferred group changed".

No assertion reads the certificate's signature. A change there is recorded as "Signature algorithm changed", without an alert.

To see what your endpoint does today, run this with OpenSSL 3.5 or later. If the output includes Negotiated TLS1.3 group: X25519MLKEM768, it accepts the hybrid.

openssl s_client -connect example.com:443 -groups X25519MLKEM768 -brief </dev/null
Now

PQC check

Run the same PQC check on your own domain.