QUIC and HTTP/3

Initial packets are encrypted. They are also readable by every observer on the path, because both facts are true at once: the key is derived from a value that travels in the clear, using a salt printed in the RFC. This is not a flaw - it is integrity protection against blind injection, not confidentiality - but it is routinely misread as "QUIC encrypts the handshake".

Same HKDF-Expand-Label as TLS 1.3, "tls13 " prefix included - see the key schedule on the TLS page. The server side is identical with the label "server in". Every value above was re-derived for this page and matches RFC 9001 Appendix A byte for byte.

Applied after payload encryption, over the bits an observer could otherwise use to correlate packets: the low bits of the first byte and the packet number.

Sent when a server wants to validate the client's address before committing state. It carries a token the client must echo, and a 16-byte tag computed with a key published in the RFC. Provenance note: every other byte on this page was re-derived from field values; these 16 tag bytes are RFC 9001 Appendix A.4's published value, reproduced as-is rather than recomputed.

A QUIC packet has no payload structure of its own - it decrypts to a stream of frames, each self-describing, read until the packet runs out. Almost every length and identifier in QUIC is a variable-length integer, so the encoding is worth reading first.

The top two bits of the first byte give the total length. All four RFC 9000 Appendix A.1 test vectors, concatenated.

Offset and length, then raw handshake bytes. The first 16 bytes of the same ClientHello decoded on the TLS page.

Type byte 0b00001OFF: the low three bits say whether Offset and Length are present and whether this is the final frame. Here all three are set.

This frame acknowledges packets 8 through 10 and 3 through 5. Ranges are encoded descending from the largest, each Gap counting the unacked packets between - and both Gap and Length are stored one less than their true value, because a zero-length range is meaningless.

I = Initial, H = Handshake, 0 = 0-RTT, 1 = 1-RTT. A frame in the wrong packet type is a PROTOCOL_VIOLATION.

QUIC uses TLS 1.3 for key agreement and nothing else. There is no TLS record layer, no ChangeCipherSpec, no session ID, no EndOfEarlyData, and no version negotiation inside TLS - a QUIC connection that is not TLS 1.3 is not a QUIC connection.

The bracketed number is the packet number in that space. Initial, Handshake, and Application Data each number from zero independently, each with their own keys and their own ACK state - a lost Handshake packet cannot be acknowledged by a 1-RTT ACK, because they are different spaces.

QUIC's own negotiation rides inside the TLS ClientHello as a single extension. Flow control limits, idle timeout, and connection ID confirmation all live here.

A TCP connection is its four-tuple: change the client's IP and the connection is dead. QUIC identifies a connection by an opaque connection ID chosen by the receiver, so the addresses underneath can change without the connection noticing. That single decision is what makes handoff between wifi and cellular survivable, and it creates a linkability problem QUIC then has to spend the rest of §9 solving.

Path validation is a two-frame challenge-response with 8 bytes of unpredictable data.

A server that has lost its state cannot send a CONNECTION_CLOSE, because it no longer has the keys to encrypt one.

HTTP/3 is HTTP/2's semantics with the multiplexing deleted, because QUIC already does it. HTTP/2 built streams on top of one TCP connection and inherited head-of-line blocking at the transport; HTTP/3 maps each request onto its own QUIC stream, so a lost packet stalls only the streams whose bytes were in it.

A unidirectional stream announces its purpose with a varint stream type as its first bytes. Unknown types are not an error - the receiver abandons the stream, which is how new stream types ship without a version bump. Types of the form 0x1f * N + 0x21 are reserved to be sent and ignored, the same GREASE trick QUIC uses on versions.

RFC 9114 §7.2. A frame on the wrong stream is a connection error, not a stream error - the whole connection dies.

Frame type, length, then a QPACK-encoded field section. Four header fields in fourteen bytes.

HPACK compresses HTTP/2 headers against a dynamic table that both sides mutate in lockstep - which works only because TCP delivers in order. QUIC streams have no order between them, so a table update on one stream may arrive after a reference to it on another. QPACK is HPACK rebuilt around that fact.

RFC 9204 §4.5. The high bits of the first byte select the form; the remaining bits are a prefixed integer that may continue into further bytes.

Two prefixed integers in front of every field section, and the whole reason QPACK can decode out of order.

Each endpoint opens one of each, as unidirectional streams typed 0x02 and 0x03. Both are critical: closing either is a connection error.

JA4q is JA4 with the protocol character q. Everything else about the derivation is identical, because the input is the same TLS ClientHello - it just arrives inside CRYPTO frames in an encrypted Initial packet instead of a TCP stream. As the Initial & Keys tab shows, that encryption stops nobody.

Example value carried over from the JA4+ breakdown so the two pages agree. The hashes are FoxIO's; the structural claims below are derived from RFC 9001.

Typical browser values, not protocol requirements. Only the version row is mandated by RFC 9001; the rest is what current clients happen to send, which is exactly what makes it a fingerprint.