TLS 1.3 Integration in HTTP/3 and QUIC

TLS 1.3 in HTTP/3: Built-In, Not Bolted On

One of QUIC's most important design decisions is integrating TLS 1.3 directly into the transport layer rather than running it as a separate protocol on top.

The Traditional Stack

In HTTP/1.1 and HTTP/2, TLS is a separate layer between TCP and HTTP:

Traditional:        QUIC:
┌────────┐       ┌────────┐
│ HTTP   │       │ HTTP/3 │
├────────┤       ├────────┤
│ TLS    │       │ QUIC   │
├────────┤       │+TLS1.3│
│ TCP    │       ├────────┤
└────────┘       │ UDP    │
                   └────────┘

Why Integration Matters

Fewer round trips: TCP requires a handshake before TLS can begin. QUIC combines both into a single handshake, saving 1 RTT on every new connection.

Always encrypted: QUIC encrypts almost everything, including transport-level metadata like packet numbers and connection close frames. With TCP+TLS, the TCP headers, handshake, and connection metadata are sent in plaintext, making them visible to middleboxes.

No downgrade: HTTP/3 always uses TLS 1.3. There is no option to disable encryption or use older TLS versions. This eliminates an entire class of downgrade attacks.

What QUIC Encrypts

• All application data (same as TLS)
• QUIC packet headers (except the first byte and Connection ID)
• Packet numbers
• ACK frames
• Connection close reasons

What Remains Visible

• The UDP 4-tuple (source/dest IP and port)
• The initial QUIC handshake packets (enough for middleboxes to identify QUIC)
• Connection ID (needed for routing)

Impact on Middleboxes

Because QUIC encrypts more than TCP+TLS, firewalls and intrusion detection systems have less visibility. This is a deliberate design choice: it prevents middleboxes from interfering with protocol evolution (a problem called protocol ossification), but it can cause QUIC to be blocked on some enterprise networks.