What actually binds your HTTP/2 connection to the TLS handshake, and why does that prevent a class of attack?

What actually binds your HTTP/2 connection to the TLS handshake, and why does that prevent a class of attack?

The binding agent is ALPN, and the attack it forecloses — ALPACA — is a precise lesson in cross-protocol confusion.

Application-Layer Protocol Negotiation (ALPN, RFC 7301) is a TLS extension where the client lists the application protocols it speaks (h2, http/1.1, and so on) inside the ClientHello, and the server picks one. The selection happens during the handshake, so by the time encryption starts, both sides agree on the protocol — no separate, unprotected negotiation round.

Why this is a security feature, not just an efficiency one: the chosen protocol is part of the authenticated handshake. The ALPACA attack (2021) exploited servers that authenticate a TLS connection but don't verify it's being used for the intended protocol — an attacker could redirect an HTTPS request to, say, an FTP or SMTP server sharing the same certificate, and the mismatched-but-valid TLS connection would proceed, enabling content injection.

The defense is to make the server enforce that the negotiated ALPN protocol matches what the service actually speaks, rejecting mismatches. ALPN provides the in-handshake signal needed to do that strictly. It is also what lets HTTP/2 negotiate without the old, slower Upgrade-header dance over plaintext.

Further reading: RFC 7301; the ALPACA attack paper (Brinkmann et al., USENIX Security 2021); RFC 9113 (HTTP/2).

Bottom line: ALPN negotiates the application protocol inside the authenticated handshake — enforcing that the negotiated protocol matches the server's actual service is what shuts down ALPACA-style cross-protocol attacks.