⚛️ Post-Quantum Web Analyzer

The third version of HTTP (RFC 9114, June 2022). It runs over QUIC instead of TCP, so it needs a UDP path to the server, and TLS 1.3 is built into the transport rather than layered on top.

A transport protocol over UDP (RFC 9000) with TLS 1.3 built into its handshake (RFC 9001). It sets up the connection and the encryption in one round trip, carries independent streams so a lost packet stalls only its own stream, encrypts packet numbers and most of the transport metadata TCP sends in the clear, and lets a connection move between networks. QUIC version 2 (RFC 9369) is the same protocol under a new version number, so middleboxes cannot ossify on version 1.

A browser reaches a site over TCP first unless the site tells it otherwise: in an Alt-Svc response header naming h3, or in a DNS HTTPS record (RFC 9460) with alpn h3, which lets it use HTTP/3 from the first connection. The scanner checks both. A server that serves HTTP/3 but advertises it nowhere is never reached over it, and one that advertises HTTP/3 but does not answer over UDP makes browsers try a path that fails; the scan says which, and neither counts as HTTP/3 a browser can find and reach.

One grade for the whole scan, from two measures. Adoption is the weighted share of what the scan looks for that the site has deployed: the core counts 6 each (post-quantum key exchange over TLS on TCP, post-quantum key exchange over HTTP/3, HTTP/3 a browser can find and reach and TLS 1.3), the hardening 4 (no TLS version older than 1.3, 0-RTT off, post-quantum key exchange chosen even when a client lists a classical group first, standard ML-KEM without the pre-standard Kyber drafts, a DNS HTTPS record naming h3, DNSSEC and a certificate within its validity period), the frontier 2 (Encrypted Client Hello, encrypted DNS at every name server, post-quantum key exchange on every encrypted DNS answer, post-quantum key exchange at every mail exchanger, where the domain receives mail, an ML-DSA certificate and delegated credentials) and the capabilities 1 (QUIC v2, WebTransport and CONNECT-UDP). Conformance is the share of the RFC checks the scan holds what is deployed to that it passes, area by area and averaged over the areas, so none weighs more for running more checks: HTTP/3 under protocol violation, QUIC under loss and a moved address, the QUIC port's application protocols, Encrypted Client Hello, DNSSEC, the name servers and delegated credentials, with a MUST counting three, a SHOULD one and the RFC's less specific answer half. A++: at least 95% adopted and 98% conformant, with post-quantum key exchange over TLS on TCP and over HTTP/3; A+: at least 85% adopted and 95% conformant, with post-quantum key exchange over TLS on TCP and over HTTP/3; A: at least 70% adopted and 90% conformant, with post-quantum key exchange over TLS on TCP and over HTTP/3; B: at least 55% adopted and 80% conformant; C: at least 40% adopted and 70% conformant; D: at least 25% adopted and 50% conformant; F: short of D: less than 25% adopted or 50% conformant. The result shows each grade's requirements met or not, and what the next one needs.

It lets a returning client send its first request together with the handshake, saving a round trip, but that early data has no protection against replay (RFC 8446, section 8): an attacker who captures it can send it again, and a request that changes something can run twice. 0-RTT off counts toward the grade only where the scan has shown the server offers no early data.

A browser API for low-latency, two-way communication over HTTP/3, with many streams and unreliable datagrams on one QUIC connection, for games, live media and collaborative tools. The scanner opens a WebTransport session on ports 443 and 4433, or on a port you give, and separately tests WebTransport over a dedicated QUIC connection (ALPN wq-vvv-01).

Yes. QUIC uses the TLS 1.3 handshake, so the same hybrid groups work, such as X25519MLKEM768 (RFC 10024), which current browsers offer by default. The scanner samples the key exchange of five QUIC handshakes, and the A grades require standard ML-KEM on every one: HTTP/3's own, since the QUIC listener is often other code than the TCP one. It also asks every key-exchange group on its own over TLS on TCP, QUIC v1 and QUIC v2, one ClientHello at a time, and shows each group's rank in the server's order on each transport, what a post-quantum client and a classical-only client each get, and where the transports disagree; each name server gets the same over DNS over TLS, DNS over QUIC and DNS over HTTPS. The PQC tab shows the site's whole post-quantum readiness.

The scan's post-quantum assessment of the site, recorded in the PQC directory: what a browser's handshake gets across five handshakes; every TLS 1.3 key-exchange group offered on its own, by kind; the server's order of preference and whether it insists on post-quantum key exchange when a client lists a classical group first; TLS 1.2, 1.1 and 1.0; whether it presents an ML-DSA certificate when asked for one; the key exchange over HTTP/3; whether ECH is accepted; CNSA 2.0 requirement by requirement; the key exchange of each transport; and every post-quantum scan of the domain. Its findings are what the grade's post-quantum items read, its recommendations join the others in Recommendations, and the figures across every domain measured are below the results.

Each adoption item names the frameworks that ask for it. NIST IR 8547 (final, October 2026) deprecates classical key establishment (ECDH, finite-field DH, RSA) and classical signatures (ECDSA, EdDSA, RSA) after 2030 and disallows them after 2035. OMB M-26-15, which it cites, requires high value assets and high impact systems to reach quantum-resistant key establishment by 31 December 2030, and federal systems to support TLS 1.3 by 2 January 2030. NSA's CNSA 2.0 asks for ML-KEM-1024, ML-DSA-87 and TLS 1.3 alone. The labels say what each one asks of the item; a met item is a measurement, not a certification against any of them.

Yes. It reads the domain's MX records from its own uncached resolver, as a mail server would, and asks each mail exchanger over SMTP's STARTTLS (RFC 3207) with the same post-quantum offer as its browser handshake, from the platform's node that reaches port 25. Where the domain receives mail, post-quantum key exchange at every exchanger is one of the grade's frontier items; a null MX (RFC 7505) accepts no mail and has none. An exchanger that offers no STARTTLS takes its mail in the clear, and is recorded as classical.

Each browser's own TLS 1.3 offer, its groups in order and the ones it sends key shares for, from each browser's documentation and source, sent to the site with real key shares over TLS on TCP and over QUIC, and the group the server picks from it or asks for in a HelloRetryRequest. A server chooses from what a client offers, so one browser can get ML-KEM where another gets a classical group. Beside each, how that browser finds the site's HTTP/3 from the DNS HTTPS record: Chrome and Edge reads it where Chrome's built-in DNS resolver is in use (Windows, macOS, ChromeOS, Android); the record's port parameter is not followed; Firefox reads it with DNS over HTTPS, or from the system resolver where network.dns.native_https_query is on; Safari and Apple's networking reads it from the system resolver, since iOS 14 and macOS 11; otherwise each learns it from Alt-Svc on its second connection. The sources are linked under the table.

Every scan records its adoption and conformance. Posture Over Time draws them across the domain's scans that the same grader graded, with where they started and where they are now, since shares from two versions of the grade are not one series; the grade card places this scan's adoption among the latest scans of every other domain in the directory graded the same way.

From the scan's own measurements, one rung at a time: the grade is the first whose requirements are all met. What the scan could not measure counts neither way. A requirement it could decide is left undecided, the grade stops below that rung, and the result says up to which grade it is withheld for want of evidence rather than held against the site; the timeline compares that ceiling, so a probe that did not answer is not read as the site moving. The post-quantum items read the scan's own post-quantum assessment, which it records in the PQC directory.

Yes. Each check opens a QUIC connection of its own, sets up HTTP/3 correctly, then breaks one rule of RFC 9114 or RFC 9204: a second control stream, SETTINGS twice, a frame type HTTP/2 used, DATA before HEADERS, a malformed request (no :method, an uppercase field name, a connection header, a wrong content-length), or a QPACK reference that cannot exist. The RFC names the error the server must answer with, so the check reads the code the server closes the connection or resets the stream with. A request sent after each violation tells a server that ignored it from one that stopped responding. Rules a server must ignore, such as reserved frame types, settings and error codes, pass when that request is still answered. The extension rules of RFC 9218 (PRIORITY_UPDATE) and RFC 9297 (HTTP Datagrams) are judged only where the server implements them, and ignoring them otherwise is reported, not failed. Every check lists its RFC section, its MUST, SHOULD or MAY, what was sent, what was expected and what the server did.

Yes, by making the path bad on purpose. The scanner connects through a socket that sees every datagram the server sends and can drop some. It advertises that it takes datagrams of 1200 bytes, the least QUIC allows, and records the largest the server sends anyway (RFC 9000 calls that limit a constraint like the path MTU). It fetches the page with no loss, then with one datagram in five dropped, and compares how long each took, which is the server's loss recovery at work. It moves to a new UDP port mid-connection, as a home router's NAT does, and checks that the server answers there and validates the new address with a PATH_CHALLENGE, as RFC 9000 requires. And it allows the server only two connection IDs, the RFC's minimum, to see whether it keeps to the limit and still leaves one spare to move with.

By making a packet go missing and watching what the server does. A congestion controller is defined by its answer to loss, so the scanner pulls the largest static file the page links (or the page) over several streams of one connection through a socket that sees each datagram the server sends, counting them round trip by round trip. Once the server is sending enough a round to read a cut from, the socket drops one datagram. The server learns of it from the scanner's acknowledgements a round later and adjusts: NewReno halves what it sends (RFC 9002), CUBIC cuts to 70% (RFC 9438), and a controller that models the path, as BBR does, keeps growing through a single loss. Where there is no cut, a burst of lost datagrams follows, which BBRv2 and BBRv3 back off from and BBRv1 does not. Up to three trials run on fresh connections and a controller is named only where they agree, since a single run can catch a server changing phase. The report shows the rounds, each loss with what the server sent before and after, each trial and the confidence; a page too small, a round trip too short to tell rounds apart, a cut between the bands, or one deeper than a halving (an answer to losses the path made too) is reported as indeterminate with the reason.

QUIC carries no application of its own: the TLS handshake inside it agrees one by name (ALPN), and RFC 9001 section 8.1 makes a server that speaks none of the names offered end the handshake with no_application_protocol. So one handshake per protocol family, on the port HTTP/3 answers, tells which the port speaks, and the name the server picks tells which version: HTTP/3 and its drafts, DNS over QUIC and its drafts, SMB over QUIC, Media over QUIC Transport, WebTransport over QUIC, MQTT, EPP over QUIC, SNIF over QUIC and the interop protocol. Two more offer names no QUIC server may pick: a reserved GREASE name, and HTTP/2 and HTTP/1.1, which are defined over TLS on TCP alone. Refusing with any code other than no_application_protocol, picking one of those names, or completing a handshake without picking a protocol is reported as a violation of RFC 9001.

Yes. A delegated credential (RFC 9345) is a short-lived key the certificate's key signs, so a server can sign its handshakes without holding the certificate's key, and a stolen handshake key expires within days. A client has to ask for one, and the credential travels in the encrypted part of the TLS 1.3 handshake, so the scanner makes that handshake itself, over TCP and again over QUIC, since the two are often different TLS stacks: a ClientHello offering the extension with an X25519MLKEM768 key share, the key schedule, and the server's handshake decrypted up to CertificateVerify. A credential received is held to section 4.1.3: its signature against the certificate's key, CertificateVerify against its own key and the algorithm it names (ML-DSA included), at most seven days left, and a certificate that carries the DelegationUsage extension. A server that sends them over one transport and not the other is reported, since its other listener still holds the certificate's key. To see one, scan delegated-credential.conformance.pqcrypta.com: its QUIC listener sends ML-DSA-87, ML-DSA-65 and ECDSA P-256 credentials, minted every six hours.

It checks it itself. The records come through a resolver that keeps nothing, with checking disabled so that data the resolver would refuse still arrives, and every signature is then verified by the scanner: from the root's trust anchor down through each zone's DS and keys to the domain's own. It reports how long the signatures have left, which keys have a DS and which sign the key set (where a key rollover stands), whether the CDS and CDNSKEY records a parent would act on keep the delegation working, and whether every name server serves the same keys and serial, validly signed, over UDP, TCP, DNS over TLS, DNS over QUIC and DNS over HTTPS. Where the domain publishes a TLSA record for HTTPS, it is matched against the certificate the site actually serves.

On request, from the Performance tab, it sends the same requests over all three, interleaved so that each round asks every protocol once and the one that goes first rotates: whatever the network does during the run falls on all three alike. It times new connections, resumed ones, HTTP/3 requests sent in 0-RTT early data, requests on a connection already open, eight requests at once, and transfers of 64 KiB and 1 MiB. Every result is a distribution with its median and spread, and two protocols are called different only when the 95% interval for the difference between them, from the Hodges-Lehmann estimate and the Mann-Whitney statistic, excludes zero. It also reports what the server did: whether it resumed sessions, accepted early data, or needed a HelloRetryRequest.

Where the site's DNS HTTPS record publishes ECH configs, the scanner uses each one in a real handshake, over TLS on TCP and over QUIC, and reads whether the server accepted it (RFC 9849 section 7.2). It then checks that the server recovers a client that is out of date: a config with the right ID but a key the server has rotated out, and a config ID it never issued, must both be rejected with retry configs the client can use. It sends a GREASE extension, which must be answered with a normal handshake, and offers ECH with a key share the server does not take, so the offer has to survive a HelloRetryRequest. Last, it checks that the retry configs match the published ones and that a client that takes them is accepted. Each check is listed per transport with its RFC section and what the server sent.

DNS carried over QUIC (RFC 9250, May 2022), on UDP port 853 with the ALPN token doq. Each query has a QUIC stream of its own, with message ID 0 and a two-octet length prefix, so a slow answer holds up no other; QUIC's TLS 1.3 handshake encrypts queries and answers, padding (RFC 9250 section 5.4) hides their sizes, and a returning client can send a query in 0-RTT data. It is used between stub and resolver, between a resolver and a zone's authoritative name servers (encrypted opportunistically, RFC 9539), and for zone transfers. DNS over TLS (RFC 7858) is the same idea on TCP port 853; DNS over HTTPS (RFC 8484) carries DNS messages in HTTP requests.

Every visit to a domain starts with a DNS lookup that ends at its authoritative name servers, before any QUIC or TLS to the site. A resolver that encrypts to those servers keeps which names are looked up from anyone on the path, and with a post-quantum key exchange keeps them private from a future quantum computer too. DNS over QUIC is QUIC beyond the web, so the scanner that measures a site's QUIC measures its name servers' as well. The result does not change the HTTP/3 grade, which is about the origin: it has its own card, recommendations and corpus statistics.

Each name server the parent zone delegates the domain to (up to four) is asked at its first address over DNS over QUIC and DNS over TLS on port 853, and over DNS over HTTPS on HTTP/2 and HTTP/3 at the path its RFC 9461 discovery record names (else /dns-query on 443). Each is asked the scanned name's SOA without recursion, so an answer with the AA bit shows the server answering for the zone. Each line gives the time, the key exchange the handshake used (post-quantum or classical, judged by its code point), the TLS version, cipher and ALPN, whether the certificate is publicly trusted, whether it also verifies for the address when the server is asked again by address with no server name, and where a failed transport stopped. Under those: the server's discovery record against what answered, its address's reverse name and network, up to 73 conformance checks, and for the zone the SOA timers and whether every name server sits in one network.

Each check (up to 73 conformance checks on a server that answers every transport) cites the requirement it tests (an RFC and section) and reports pass, fail (a MUST broken, or an opening for abuse), warn (a SHOULD or a recommendation missed), info, not applicable or not tested, with what was seen; a verdict concluded from timing rather than seen on the wire is marked inferred. Over port 53 they cover the DNS message, EDNS(0), DNS Cookies, TCP, truncation and fragmentation, DNSSEC, EDNS Client Subnet, open recursion, identity and response rate limiting. Over DNS over QUIC they cover RFC 9250's mapping: message ID 0, one response per stream and the FIN after it, stream reuse, parallel queries, padding, the protocol errors of section 4.3.3, STOP_SENDING and RESET_STREAM, the idle timeout, address validation and the anti-amplification limit, session tickets and 0-RTT. Over DNS over HTTPS they cover RFC 8484: both GET and POST, the media type, message ID 0, a 2xx status for a DNS error such as NXDOMAIN, the HTTP cache lifetime against the answer's TTLs and the SOA MINIMUM, the EDNS payload size ignored, padding, the status for a request that is not a DNS query, and cookies. The RFC 9250 and RFC 8484 tabs list all 47 of RFC 9250's and 28 of RFC 8484's requirements, each with the checks that cover it, the client rule the probe follows, or why it cannot be seen from outside the server. Checks that test a server as a whole run at most once per address every six hours, and a slow server's unfinished checks read not tested rather than holding up the scan.

Resolver compatibility is the share of the checks a resolver depends on that pass (answers over UDP and TCP, truncation, fragmentation, EDNS, cookies, DNSSEC; DNS over QUIC's message ID, FIN, single response, stream reuse, parallel queries and resumption; and DNS over HTTPS's methods, media type, message ID, status for DNS errors and ignored payload size), a warning counting half. Privacy counts what keeps a query hidden: how many of the four encrypted transports answer (DNS over QUIC, DNS over TLS, and DNS over HTTPS over HTTP/2 and HTTP/3), how many of those used a post-quantum key exchange, padding, no client subnet asked for, connection migration off, and no HTTP cookies. Neither changes the HTTP/3 grade.

Yes, separately from the site's own 0-RTT. RFC 9250 section 4.5 allows a query in 0-RTT data, since a replayed query only repeats an answer, but nothing that changes state. The scanner takes a session ticket, reads its lifetime, resumes with it, sends a QUERY in 0-RTT data, and sends an UPDATE in 0-RTT data that the server must hold back (our own name servers refuse it with Extended DNS Error 26, Too Early). The Performance tab compares a full handshake, a query on an open connection, eight queries at once, a resumed connection and 0-RTT. None of this changes the HTTP/3 grade, whose 0-RTT check is about the web server.

DNS over HTTPS (RFC 8484) sends a DNS message in an HTTP request (the scanner POSTs the query) over HTTP/2 or HTTP/3 on port 443, the port almost no network blocks. RFC 9461 lets a name server say which encrypted transports it serves in an SVCB record at _dns.<its name>, for example _dns.ns1.pqcrypta.com. SVCB 1 ns1.pqcrypta.com. alpn=dot,doq,h2,h3 dohpath=/dns-query{?dns}, as one of ours publishes it. The scanner reads the record from the zone's own servers, asks DNS over HTTPS where its dohpath and port say, and shows which advertised protocols did not answer and which answered without being advertised.

Knot DNS 3.3 and later serve it directly: listen-quic on the server's addresses at port 853 (listen-tls, from 3.4, for DNS over TLS), with key-file and cert-file naming a certificate for the server's name; a self-signed one works for resolvers that encrypt opportunistically (RFC 9539), and a publicly trusted one also lets them authenticate the server. Put the server's addresses on it too (RFC 8738; Let's Encrypt issues them under its shortlived profile) and present it when a client sends no server name, so a client given only the address can authenticate the server as well. In front of another authoritative server, dnsdist 1.9 and later accepts DNS over QUIC and DNS over HTTPS and forwards plain DNS. Open UDP and TCP 853 on every firewall in the path, publish the _dns SVCB record, and for a post-quantum handshake build with a TLS library that has ML-KEM (OpenSSL 3.5, or GnuTLS with leancrypto): stock Knot offers classical groups only, which is why our own name servers run a patched build. Then scan the domain here, or run the kdig commands on the card's Reproduce tab.

They are what other name-server checkers flag, and each is checked against its own reference. Reverse name: RFC 1912 section 2.1 asks that every reachable address have a PTR that resolves back to it; the card also says whether it is the server's own name. Network: RFC 2182 section 3.1 asks for name servers in different networks, so the card shows each address's ASN and warns when all of them share one, since one outage there takes the zone off line. SOA timers: refresh, retry and expire against RFC 1912 section 2.2, and the negative-caching TTL against RFC 2308 section 5, with whether every name server serves the same serial.

A scan measures, and a measurement takes as long as the site takes to answer, or as long as a probe waits for an answer that does not come. It starts by resolving the name from the root down, with nothing cached, because the address has to be known to be public before anything connects; a name whose servers are far away or slow shows here first. The probes that need nothing else then start together: the post-quantum assessment over TCP (the browser handshake first and alone, then the older TLS versions, the key exchange over TCP, the ML-DSA certificate, HTTP/3's key exchange and ECH), the content over each protocol, and DNS at the name servers with the DNSSEC chain after it. The ones that need to know where HTTP/3 is served start once the protocol probes have answered. A site far away pays its round trip on every question the key exchange enumeration asks, one at a time, so as not to look like an attack, and a site with nothing on UDP makes the HTTP/3 probe wait out its whole handshake budget. The Scan Timeline card shows when each probe ran and for how long, and while a scan runs the status lists each probe as it starts and finishes.

It follows a site the way a browser reaches it, then pushes it. It reads the DNS HTTPS record and the Alt-Svc header, connects over HTTP/3, HTTP/2 and HTTP/1.1, and records what each connection negotiated: QUIC version, transport parameters, TLS key exchange, HTTP/3 SETTINGS and the certificate chain. It makes a post-quantum assessment (a browser's handshake five times, the older TLS versions, an ML-DSA certificate, HTTP/3's key exchange, ECH and CNSA 2.0) and records it in the PQC directory. It asks for every key exchange group over TLS on TCP and over each QUIC version, uses each published Encrypted Client Hello config in a real handshake, and verifies DNSSEC from the root itself. Then it breaks rules on purpose, each on a connection of its own: HTTP/3 violations judged by the error the server must answer with, dropped datagrams and a moved address, a lost datagram to tell the server's congestion controller, application protocols the QUIC port should refuse, and a handshake that offers delegated credentials. It tests the extensions too, 0-RTT, WebTransport, a MASQUE CONNECT-UDP session relaying real UDP, an RFC 9218 PRIORITY_UPDATE frame and QUIC multipath by opening a second path, and asks each of the domain's name servers for an answer over DNS over QUIC, DNS over TLS and DNS over HTTPS, running up to 73 conformance checks on each. Every result carries the version of the scanner that measured it.