PQ CRYPTA PLATFORM

🏠 Main

πŸ“° News

πŸ‘€ Account

⟨ QUANTUM ERROR PORTAL ⟩

Navigate the Error Dimensions

πŸš€ Analyze QUIC & HTTP/3 Security, Post-Quantum TLS & Performance

πŸ”What it does: connects to any site over real QUIC and reports what the server actually negotiated, not a simulation.
πŸ…What you get: a grade from A++ to F, with post-quantum key exchange required for the top tier, plus per-scan recommendations.
πŸ“ŠWho it's for: a clear verdict for anyone, deep transport metrics for engineers who want the details.

HTTP/3 with QUIC and WebTransport delivers faster page loads and mandatory TLS 1.3 encryption. Our scanner uses native QUIC libraries to extract real peer-advertised metadata, from transport parameters and HTTP/3 SETTINGS to certificate chains and post-quantum key exchange, and grades every site on a 5-tier scale (A++, A+, A, C, F). Curious how a scan actually works on the wire? Read Anatomy of a QUIC Connection, our whitepaper that replays one real scan packet by packet.

Full analysis coverage: every metric the scanner extracts

The scanner extracts detailed metadata including real peer-advertised QUIC transport parameters, HTTP/3 SETTINGS (QPACK, Extended CONNECT, datagrams), server implementation fingerprinting (identifying Cloudflare, Google GFE, Facebook mvfst, Fastly H2O, and more), connection metrics (handshake time, TTFB, RTT, GSO, probe timeouts), certificate chain analysis (OCSP stapling, Certificate Transparency, root CA), and TLS extension analysis. The 5-tier grading requires post-quantum hybrid key exchange for the top tier and produces intelligent per-scan recommendations.

  • HTTP/3 and QUIC protocol detection with native noq/h3 QUIC libraries (multipath-capable); QUIC v1/v2 (RFC 9369) and Version Negotiation detection, TLS 1.3
  • Post-quantum hybrid key exchange detection (e.g. X25519MLKEM768), required for the A++ grade tier
  • Server fingerprinting: Identifies Cloudflare, Google GFE, Facebook mvfst, Fastly H2O, and more
  • QUIC transport parameters: real peer-advertised flow control, stream limits, GREASE bit, connection migration, preferred address
  • HTTP/3 SETTINGS: QPACK dynamic table, Extended CONNECT, WebTransport (including SETTINGS_WEBTRANSPORT_MAX_SESSIONS), datagrams, RFC 9218 Extensible Priorities (real active PRIORITY_UPDATE test)
  • QPACK encoder and decoder unidirectional streams (RFC 9204 Β§4.2): whether the peer opens them at all, which separates implementations that do so unprompted from those that wait to be asked
  • Connection metrics: handshake time, TTFB, RTT (including real minimum), bytes in flight against the congestion window, GSO detection, ACK frequency, probe timeout count
  • Certificate chain analysis: OCSP stapling, Certificate Transparency/SCT, root CA, PQC-signed certs, and RFC 9345 delegated-credential authorisation (the DelegationUsage extension together with digitalSignature KeyUsage)
  • TLS extension analysis: ALPN protocols, key share groups, ECH support, certificate compression, 0-RTT early data
  • WebTransport capability testing: datagram support/size, flow control, stream limits, session-open latency (ports 443, 4433, or custom)
  • MASQUE CONNECT-UDP (RFC 9298) detection with real UDP-over-HTTP/3 relay verification
  • draft-ietf-quic-multipath capability probe with genuine cryptographic second-path validation
  • WebTransport over a dedicated QUIC connection (draft-vvv-webtransport-quic), probed by offering the registered ALPN token wq-vvv-01 β€” a different transport from WebTransport over HTTP/3, and one QUIC answers definitively because ALPN negotiation must succeed for the handshake to complete
  • DNS HTTPS record (RFC 9460 type 65) fully parsed: alpn, port, ECH and IP hints, with the scan following any non-standard UDP port the record steers browsers to
  • Cross-protocol content comparison: the same URL fetched over HTTP/1.1, HTTP/2 and HTTP/3 and SHA-256 hashed, with a control fetch and per-request-token normalization (CSP nonces, CSRF tokens, timestamps) so even dynamic sites get a definitive answer on whether content differs by transport path
  • HTTP/3 discovery analysis over both paths β€” Alt-Svc headers and DNS HTTPS records (RFC 9460) β€” plus 0-RTT replay attack risk assessment
  • Every scan is kept, so a domain accumulates a timeline rather than a single verdict β€” the public directory shows each origin's most recent result, and the report carries the posture record behind it
  • Posture movement between consecutive scans, classified as it happens: grade changes, a post-quantum key exchange gained or lost, TLS version moves, HTTP/3 or Alt-Svc disappearing, an origin going dark and coming back
  • Intelligent, context-aware recommendations with 3-tier fingerprinting confidence scoring
Enter domain or full URL to scan
Optional
Default: /, /webtransport
Default: 443, 4433

Analysis target: by default, the exact hostname you enter — the analyzer grades that host's own response and does not follow redirects. If a site redirects (e.g. example.com → www.example.com, or to a different domain), HTTP/3 may live on the target, not the apex. Enable Follow redirects — the checkbox above — to instead analyze the final destination; the result clearly shows which host was actually analyzed.

Try these examples:

πŸ’‘ Three Ways to Use:
Query: ?url=pqcrypta.com
Path: /pqcrypta.com
Manual: Enter URL above

πŸ“Š Scan Results live

πŸ† A++ (0)

Ultimate: HTTP/3 a browser can find, 0-RTT shown to be off, WebTransport, and a post-quantum hybrid key exchange negotiated.

Loading...

βœ… A+ (0)

Excellent: HTTP/3 with QUIC protocol. 0-RTT disabled for maximum security.

Loading...

⚑ A (0)

Good: HTTP/3 with QUIC protocol. Either 0-RTT is enabled (replay attack risk), or this scan could not establish whether it is β€” A+ needs 0-RTT shown to be off.

Loading...

⚠️ C (0)

Misconfigured: HTTP/3 is served but never advertised, or advertised but unreachable.

Loading...

❌ F (0)

Failed: No HTTP/3 support detected. Using legacy HTTP/2 or HTTP/1.1 protocols only.

Loading...

🌐 Across Every Domain Measured live

How common each capability is among the origins this scanner has actually connected to. Every rate below is shown with the population it was measured over, because they are not the same population: a QUIC transport parameter can only be read where a QUIC handshake completed, a TLS group is negotiated over TCP as well, and a DNS record is resolved without connecting to anything.

Loading…

From substrate to usable capability

Each rung is a narrower question than the one above it, so the fall between rungs localises where a technology stops being available: at the transport, at the handler, or at the door. Advertising a capability and letting an anonymous client use it are not the same claim, and the gap between them is the finding.

By server implementation

Only implementations with at least ten domains in the sample. A percentage over four domains is not a rate.

HTTP/3 and post-quantum adoption by server implementation
ImplementationDomainsHTTP/3PQ key exchange

Movement between observations

What this scanner does not measure

A field that is empty on every scan reads from outside as a measured absence. These are the ones we never look at, and why β€” so a null can be told apart from a finding. Grouped by reason, because most of them are not limits on what is knowable: they are work we have not done, and they say what the work is.

Which instruments produced these rows

Held out of these rates

These figures are free to reuse under CC BY 4.0, credited to the PQ Crypta Post-Quantum QUIC & HTTP/3 Analyzer. Every figure, as JSON: api.pqcrypta.com/http3-scanner/corpus.

Scan it from your own tooling

Everything on this page is rendered from four JSON endpoints on api.pqcrypta.com. The page is one client of them, not the only one β€” a script, a CI job or a monitoring check reads exactly the same fields the panels above do, with no browser and no HTML parsing.

HTTP/3 scanner API
EndpointAuthReturns
POST /http3-scanner/scan API key One scan of one origin β€” the whole result object behind every panel above, including grade, grade_reason, quic_transport_params, tls_extensions, not_measurable and the probe_version / grader_version stamps that say which instrument produced it.
GET /http3-scanner/corpus none Capability adoption across the scanned corpus, each rate with its own denominator, plus the derivation contract version the figures were computed under.
GET /http3-scanner/timeline none The history behind Posture Over Time for one domain: what changed between observations, with the runs where nothing moved collapsed. Takes ?domain= and an optional limit. A scan describes one observation; this is the series, and no scan response can carry it.
GET /http3-scanner/stats none The public directory: grade distribution and the scans listed in each grade card.

Calling it

Send the key as X-API-Key. Any key carrying the general endpoint scope works; keys are issued per account. A scan makes several real connections to the origin you name and can take tens of seconds, so allow a generous client timeout β€” set --max-time well above the 40-second scan ceiling rather than at it.

curl -s https://api.pqcrypta.com/http3-scanner/corpus

curl -s --max-time 120 -X POST https://api.pqcrypta.com/http3-scanner/scan \
  -H 'Content-Type: application/json' \
  -H "X-API-Key: $PQCRYPTA_API_KEY" \
  -d '{"url":"example.com"}'

No browser User-Agent is required or expected on these paths β€” a default curl, python-requests or SDK agent string is served normally. No value on this page is measured in its JavaScript; every panel is rendered from a response. The page derives presentation from those fields β€” counts like “9 of 10 sent”, units, and formatting β€” but nothing it shows was observed anywhere except in a response above.

Every panel on this page comes from one of those four, Posture Over Time included.

What is HTTP/3 and QUIC?

HTTP/3 is the latest version of the Hypertext Transfer Protocol (RFC 9114), standardized by the IETF in June 2022. Unlike HTTP/1.1 and HTTP/2 which run over TCP, HTTP/3 uses QUIC (Quick UDP Internet Connections) as its transport layer. QUIC operates over UDP with mandatory TLS 1.3 encryption built directly into the transport protocol, combining the transport and cryptographic handshakes into one round trip and recovering lost packets per stream rather than stalling every stream behind one retransmission. How much of a speed difference that makes depends on the loss and latency of the path and on how much of the page is fetched concurrently.

⚑ Performance Benefits

Faster Connections: QUIC combines the cryptographic handshake with connection establishment (1-RTT), compared to TCP+TLS requiring 2-3 round trips. 0-RTT resumption enables instant reconnection for repeat visitors. Zero Head-of-Line Blocking: Independent streams prevent one slow resource from blocking others, critical for modern web applications with hundreds of assets.

πŸ”’ Security & Privacy

Mandatory Encryption: Unlike HTTP/2 where TLS is optional, HTTP/3 requires TLS 1.3, the most secure version with forward secrecy and modern cipher suites. Transport Metadata Protection: QUIC encrypts packet numbers, connection IDs, and other transport metadata that TCP exposes in plaintext, defending against traffic analysis, fingerprinting, and network-level attacks.

πŸ“± Mobile & Reliability

Connection Migration: Unique connection IDs allow seamless handoff when switching networks (Wi-Fi ↔ cellular) without dropped connections or re-authentication. Improved Loss Recovery: Per-stream acknowledgments and more accurate RTT estimation provide better performance on lossy networks (mobile, satellite, public Wi-Fi). WebTransport: Bidirectional streaming over QUIC enables real-time applications like gaming, video conferencing, and collaborative editing.

Frequently Asked Questions

What is HTTP/3?

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.

What is QUIC?

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.

How does a browser find HTTP/3?

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; both grade C.

What do the grades mean?

A++: HTTP/3 a browser can find, 0-RTT shown to be off, WebTransport, and a post-quantum hybrid key exchange negotiated. A+: HTTP/3 a browser can find, with 0-RTT shown to be off. A: HTTP/3 a browser can find, but 0-RTT is on (a replay risk) or could not be shown to be off. C: misconfigured, with HTTP/3 served but never advertised, or advertised but unreachable. F: no HTTP/3.

Why is 0-RTT a risk?

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. The scanner grades A+ or A++ only when it has shown that the server does not offer 0-RTT.

What is WebTransport?

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).

Does HTTP/3 support post-quantum key exchange?

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 records the key exchange the server negotiates, and A++ requires a post-quantum one. The PQC Readiness Scanner (pqcrypta.com/pqc-ready/) tests every key-exchange group a server accepts.

How does the scanner work?

It connects over HTTP/3, HTTP/2 and HTTP/1.1, reads the Alt-Svc header and the DNS HTTPS record, and records what each connection negotiated: QUIC version, transport parameters, TLS key exchange, HTTP/3 SETTINGS and the certificate chain. It then tests the extensions one at a time: 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. Every result carries the version of the scanner that measured it.

πŸš€ What's Next After HTTP/3 + QUIC + WebTransport?

🌐

QUIC v2 (RFC 9369) & Independent Extensions

Active Development

QUIC v2 (RFC 9369, 2024) is an anti-ossification revision, not a feature release. It has the same capabilities as QUIC v1 (RFC 9000) but changes version codepoints, salts, and TLS labels so endpoints and middleboxes keep exercising version negotiation instead of hard-coding "QUIC = v1." It adds no new transport features. The genuinely new capabilities below are separate extensions, each on its own track β€” they are not part of QUIC v2:

  • QUIC v2 (RFC 9369) shipped supported here – Anti-ossification version with the identical feature set to v1; new codepoints keep version negotiation alive. This proxy handshakes both v1 and v2 on its HTTP/3 and WebTransport endpoints β€” scan this site and the QUIC Version row lists v1 and v2.
  • ACK Frequency IETF WG draft supported here – Lets a receiver send fewer, batched acknowledgements to cut overhead on high-throughput transfers (draft-ietf-quic-ack-frequency).
  • Multipath QUIC IETF WG draft supported here – Manages multiple network paths (e.g. Wi-Fi + cellular) on one connection for failover and, depending on the scheduler, bandwidth aggregation (draft-ietf-quic-multipath). This scanner tests for it, and pqcrypta.com's own server implements the full extension (concurrent data-carrying paths, per-path packet-number spaces and loss recovery, and the complete PATH_ACK/PATH_ABANDON/PATH_STATUS lifecycle) via the noq QUIC stack β€” scan this site and the Multipath field validates a genuine second data-carrying path.
  • Forward Error Correction (FEC) research only – Proactive recovery without retransmission, useful in theory for lossy links (satellite, 5G mmWave). Google's original QUIC had FEC and removed it; there is currently no IETF standards-track draft.
  • Congestion control (BBRv3, Copa) implementation choice – RFC 9002 defines a NewReno baseline; endpoints may deploy newer algorithms today. The IETF does not standardize a specific algorithm, and "AI-driven" variants remain research.

Sources: IETF QUIC Working Group β€” RFC 9369 (QUIC v2), RFC 9002 (loss recovery / congestion-control baseline), draft-ietf-quic-multipath, draft-ietf-quic-ack-frequency. See the Technology Verification Status table below for per-feature standardization state.

πŸ”„

HTTP/3 Extensions (Actively Being Designed)

Design Phase

Future HTTP/3 enhancements being discussed in IETF HTTP WG and research communities:

  • Partial Reliability – Send only what matters, skip corrupted or outdated data. Perfect for live video where old frames are useless.
  • Unidirectional Unreliable Streams – For gaming telemetry, sensor data, and real-time metrics where loss is acceptable.
  • Server Push Redesign – HTTP/2 push was deprecated due to poor adoption. New models being explored for predictive resource delivery.
  • Better Prioritization – Smarter scheduling algorithms that understand application-level importance, not just stream priorities.
  • Native Real-Time Media Support – Primitives for video/audio streams to and from a server, without SDP negotiation. Not a substitute for WebRTC where peer-to-peer or media capture is the requirement.
  • Capsule Protocol / MASQUE – The Capsule Protocol (RFC 9297) and CONNECT-UDP (RFC 9298) are already standardized and supported by this proxy β€” the scanner verifies a real UDP-over-HTTP/3 relay end-to-end. Ongoing work extends tunneling to CONNECT-IP (RFC 9484) and arbitrary protocols (VPNs, databases, custom protocols).

Source: IETF HTTP WG, draft-ietf-httpbis-*, W3C WebTransport specifications

πŸ›°

Beyond HTTP: New Protocol Families

Research Active

Some research is exploring post-HTTP models entirely, rethinking how the internet routes and delivers content:

  • Content-Centric Networking (CCN / NDN) – Routing based on content hashes, not server IPs. Request "video/abc123" from the network, get it from the nearest cache automatically.
  • Peer-to-Peer Transport Layers – Browser-native P2P without WebRTC's connection-establishment machinery. Speculative: no specification work is underway, and NAT traversal is the hard part WebRTC already solves.
  • Encrypted-by-Default Object Protocols – IPFS-like content addressing but standardized at the transport layer. Every object is cryptographically verified.
  • Information-Centric Internet Architecture – Fundamental redesign where data flows are named and secured, not tied to specific servers or locations.

Source: IRTF ICNRG, ACM ICN workshops, Named Data Networking project

πŸ”₯

WebTransport and WebRTC

Active Development

WebTransport overlaps WebRTC's data channels and is a simpler fit for client-to-server streaming, but it is not a replacement: WebRTC also carries peer-to-peer connectivity, media capture, echo cancellation and the ICE/STUN/TURN machinery for traversing NAT, none of which WebTransport provides or plans to. Where the two are compared fairly is server-mediated data transport. Directions under discussion:

  • WebTransport over Multipath QUIC – Real-time streams that seamlessly use WiFi + cellular simultaneously for maximum reliability.
  • WebTransport with Partial Reliability – Choose reliability per-stream: reliable for chat messages, unreliable for game positions, partially reliable for video.
  • WebTransport for Real-Time Media – Codec integration paired with WebCodecs, avoiding SDP negotiation for the server-mediated case. Peer-to-peer media remains WebRTC's.
  • Browser-to-Browser WebTransport – Direct peer connections without STUN/TURN servers, using QUIC's connection migration.
  • WebTransport Pooling – Share QUIC connections across browser tabs for lower overhead and faster startup.

Source: W3C WebTransport WG, IETF QUIC WG discussions, Chrome/Firefox roadmaps

🧠

AI-Optimized Networking

Research Active

Not standards yet, but active research in academia and industry (Google, Meta, Cloudflare):

  • AI-Driven Congestion Control – Neural networks that learn network behavior patterns and optimize throughput better than traditional algorithms.
  • Predictive Packet Scheduling – ML models that predict which packets will be needed next based on user behavior and application state.
  • Adaptive Protocol Negotiation – Automatically switch between QUIC, TCP, or future protocols based on real-time network conditions and application requirements.
  • Smart Connection Migration – AI decides when to switch networks, pre-warms connections, predicts handoffs before they happen.
  • Traffic Pattern Recognition – Identify application types (video, gaming, browsing) and apply custom optimizations automatically.

Source: ACM SIGCOMM, Google Research (Remy, PCC Vivace), Meta's Robustness team

🧩

QUIC for Everything (Beyond Web)

Early Implementations

QUIC is expanding beyond HTTP/3 into databases, microservices, and system infrastructure:

  • Database Protocols over QUIC – MySQL, PostgreSQL, MongoDB replication using QUIC for better latency and connection migration. Already prototyped by Cloudflare.
  • gRPC over QUIC – Microservice RPC with 0-RTT reconnection, multiplexed streams, and better mobile support. Google is actively working on this.
  • Service Mesh QUIC Backplanes – Istio, Linkerd, Consul using QUIC for inter-service communication instead of TCP. Better observability and performance.
  • DNS over QUIC (DoQ) – RFC 9250 standardized. Faster, more private DNS queries with connection reuse. Cloudflare, Google DNS support it.
  • SSH over QUIC – Persistent remote shells that survive network changes. No more "connection lost" when switching networks.
  • IoT Protocols over QUIC – MQTT, CoAP running over QUIC for better reliability on unstable networks (satellites, cellular).

Source: RFC 9250 (DNS over QUIC), gRPC roadmap, CNCF service mesh projects

🏁

The Complete Roadmap

Summary
Layer Current Cutting Edge Next / Future Status
Transport QUIC v1 & v2 (RFC 9369), Multipath, ACK Frequency FEC, newer congestion control (BBRv3/Copa) v1+v2 live here drafts live here
HTTP HTTP/3 (RFC 9114) Partial reliability, better prioritization Design Phase
Real-Time WebTransport Multipath + media + P2P Active Dev
Architecture Client/Server Content-centric, P2P Research
Performance TLS 1.3 + QUIC AI-optimized transport Research
Beyond Web HTTP/3 + WebTransport QUIC for databases, RPC, IoT Early Impl

πŸš€ The Next Wave of Innovation

The technologies coming next are:

  • Newer congestion control algorithms beyond RFC 9002's baseline (QUIC v2 itself already shipped as RFC 9369)
  • HTTP/3 extensions with partial reliability
  • WebTransport++ for server-mediated real-time data
  • AI-optimized transport layers
  • QUIC everywhere (databases, microservices, IoT)

Timeline: QUIC v2 RFC 9369 (2024) β€” live on this server's HTTP/3 and WebTransport endpoints; Multipath QUIC still an active IETF WG draft industry-wide (this site's own server already implements full real server-side support - see the Verification Status table below); HTTP/3 extensions (2026-2027), AI-optimized (2027-2030), Content-centric networks (2030+)

πŸ“‹

Technology Verification Status

Current standardization and implementation status of emerging technologies. The "supported here" badge means this scanner has genuine testing capability for that technology against any site you scan; "partial here" means part of the question is answerable and the rest is not, with the row saying which part. pqcrypta.com's own server also implements QUIC v2, CONNECT-UDP, ACK Frequency, RFC 8879 certificate compression and full Multipath QUIC β€” scan this site and those validate as real, rather than only demonstrating that the scanner can probe for them.

Technology Status Evidence
QUIC v2 supported here βœ… Standardized RFC 9369
Multipath QUIC supported here ❌ Not standardized draft-ietf-quic-multipath-21
QUIC FEC ❌ Research only No RFC
HTTP/3 partial reliability ❌ Research only No active I-D
WebTransport multipath ❌ Not implemented No browser support
AI congestion control ❌ Research only SIGCOMM papers
DNS over QUIC βœ… Standardized RFC 9250
MASQUE CONNECT-UDP supported here βœ… Standardized RFC 9298
WebTransport over QUIC supported here ❌ Not standardized draft-vvv-webtransport-quic-02 (ALPN wq-vvv-01)
RFC 8879 certificate compression supported here βœ… Standardized RFC 8879 β€” the scanner reads which algorithm an origin compressed with, and this server compresses its own chain: 3,435 bytes to 2,376 with zlib, about 1 KB off every full handshake
RFC 9345 delegated credentials partial here βœ… Standardized RFC 9345 β€” certificate authorisation is read; whether a handshake used one needs a TLS stack offering extension 34
QUIC ACK Frequency supported here ⚠️ Draft draft-ietf-quic-ack-frequency
QUIC for databases ⚠️ Experimental Cloudflare prototypes
QUIC service mesh ⚠️ Experimental CNCF projects
Content-centric networking ❌ Research only ICNRG