Hybrid preferred
Offered a hybrid post-quantum group and a classical group together, the host picks the hybrid one. This is the posture to aim for.
Free tool
Is this host post-quantum ready?
Type a public host name. RelixQ makes three read-only TLS 1.3 handshakes and tells you whether it supports a hybrid post-quantum key exchange, whether it prefers it, and whether it is a true downgrade.
Check a host
One public host, three handshakes.
No account, no scan of your estate. Nothing is stored against you; a result is cached for 24 hours so the same host is not probed twice.
Reading the result
Supported is not the same as used.
Most checkers stop at 'does it support X25519MLKEM768'. A server can support it and still choose classical, and that is the case that leaves traffic harvestable.
True downgrade
The host proved it can do hybrid when it was offered alone, then picked classical when both were on the table. The capability exists and the configuration does not use it, usually a group-preference or a proxy setting.
No post-quantum key exchange
The host never selected a post-quantum group. That is absence of support, a different fix from a downgrade, and the tester keeps the two apart.
- The three handshakes: classical groups only, each post-quantum group on its own, then a post-quantum group and X25519 together. The group the server selects each time is what is reported.
- Only TLS 1.3 on port 443 is tested, and only the endpoint that answered. A CDN or load balancer in front of an origin is what you are seeing; the leg behind it is not tested.
- Private, loopback, link-local and other non-public addresses are refused. Limits apply per visitor and per host.
Beyond one host
RelixQ Lab verdicts and consent-gated runs are the paid product.
The tester answers one question about one public endpoint. RelixQ discovers cryptography across code, dependencies, certificates, TLS and cloud, runs consent-gated observations, and shows what to fix first.