Overview

This H3Act-related analysis separates certificate-authorized HTTP/3 connection reuse from per-request origin authorization. A client may coalesce requests for another certificate-covered origin, but the CDN must route by the current `:authority` or return 421 when the connection cannot serve it. The related draft-05 threat model requires shared certificate and listener, eligible reuse, and stale routing; it is proposed guidance, not an adopted standard.

Learning outcomes

Certificate coverage and address equivalence can permit connection reuse, but neither proves that origins share trust or application state.
Every reused request needs independent routing by current `:authority`, or a 421 response when the connection cannot serve that origin.
Different HTTP/2 and HTTP/3 behavior supports independent regression tests, not a categorical protocol safety ranking.

Keywords

H3ActCoalescingRoutingAuthorityCertificate421

The Connection Is Not the Origin

The HTTP/3 connection-contamination discussion extends H3Act's translation problem into connection-scoped state. This chapter focuses on a deceptively simple question: when a client reuses one QUIC connection for more than one origin, does the CDN authorize each request by its current :authority, or does an earlier connection decision still control the backend? Readers will be able to separate certificate-authorized connection reuse from origin authorization and understand why every new protocol path needs fresh semantic tests.

The distinction matters because reuse is part of HTTP/3's design, not an accidental exception. A persistent connection can carry many requests, and RFC 9114 allows a client to reuse it for another origin when the server certificate is valid for that origin. That saves a handshake and can reduce latency. The certificate proves something about the connection's authenticated endpoint. It does not, by itself, prove that the backend selected for every later request is authorized to serve every origin covered by the certificate.

Reuse is a feature; stale routing is the failure

Connection coalescing is the name commonly given to reusing an existing HTTP/2 or HTTP/3 connection for a second origin. The client checks whether the certificate covers the second hostname and whether the resolved addresses meet its implementation's equivalence rules. If those checks succeed, the client may send a new request with a different URI authority over the existing connection. HTTP/3's standard also gives a server a way to decline that reuse: it can respond with 421, Misdirected Request, when it cannot properly serve the requested origin on the current connection.

The security boundary appears after the client has made that choice. The CDN edge receives a request whose effective authority belongs to one origin, but the QUIC connection was established with a certificate and Server Name Indication, or SNI, associated with another. A safe routing layer treats the request's current authority as the decision input. An unsafe layer treats the first SNI, the first request, or a connection identifier as a permanent backend route.

Certificate validity and address equivalence establish whether reuse is permitted; they do not establish that two origins share application state or trust. A wildcard certificate can cover hostnames that an operator intends to isolate, and a shared listener can accept both names while routing them to different backends. That is why the client-side coalescing decision and the server-side authorization decision must remain separate. The former answers, “May these bytes use this authenticated connection?” The latter answers, “Which backend may process this request?” Only the current request's effective authority can answer the second question.

The supplied connection-contamination Internet-Draft describes the conditions for this exposure narrowly. Distinct origins must share a certificate and an HTTP/3 listener while remaining logically or organizationally isolated. The client must be willing to coalesce the connection. And the routing layer must use a connection-established signal instead of re-evaluating the effective request host for every request. All three conditions matter. Remove the shared trust surface, the eligible reuse, or the stale routing decision, and this particular exposure does not follow.

Published by DeepMox

FAQ

Does a valid certificate authorize a CDN backend for every coalesced origin?

No. It can permit connection reuse, but the CDN must still authorize and route each request using its current `:authority`; certificate scope alone does not establish backend trust.

What should a server do when a reused connection cannot serve an origin?

It should return 421, Misdirected Request, so the client can retry on a suitable connection. Suppressing that signal can remove the protocol's defense against misdirected reuse.

What conditions define the connection-contamination threat in draft-05?

The draft-05 threat requires isolated origins sharing a certificate and HTTP/3 listener, client coalescing, and routing that reuses stale connection state instead of checking each request's host. It is an older Internet-Draft, not an adopted standard.

Previous10 minH3Act: Cache Keys and Message Boundaries

Next12 minH3Act: Request-Centered Translation Security

H3Act: Connection Coalescing and Routing

The Connection Is Not the Origin

Reuse is a feature; stale routing is the failure

FAQ