Summary

  • ALPN put application-protocol selection inside the TLS handshake, avoiding a separate negotiation round trip when several protocols shared one endpoint and port.
  • The client advertises an ordered list of opaque identifiers, but the server chooses one protocol from the intersection according to its own policy; no common choice requires a fatal failure rather than silent improvisation.
  • The selected protocol belongs to one connection, not to a resumable TLS session. A ticket from an earlier connection cannot carry the old grammar forward, and a successful choice does not by itself authenticate an origin or authorize application work.

The old ticket returned to a new wire

Imagine a client reconnecting to a familiar service. It presents a valid session ticket minted during an earlier TLS connection. The old connection carried HTTP/2. The server still recognizes the ticket, so some cryptographic establishment work may be shortened.

It is tempting to treat the ticket as memory for the whole conversation. The client and server spoke HTTP/2 last time; why ask again?

Because the ticket does not own the new connection's application grammar. The endpoint may now prefer another protocol. The client may have changed its acceptable set. A load balancer may route the resumption to a node with a different deployment state. Even when the cryptographic resumption is valid, the meaning of the first application byte still needs a decision scoped to the wire on which that byte will travel.

The 2014 ALPN specification, RFC 7301, says this unusually plainly. The extension establishes a property of the connection, not of the session. When resumption or session tickets are used, the old ALPN contents are irrelevant. Only the values in the new handshake count.

That boundary is the mechanism's deepest contribution. Reuse can preserve what is safe to reuse without quietly inheriting a parser, a service role or a future policy decision.

Port numbers had stopped being a sufficient answer

For much of Internet history, a port number was a practical clue to the application above transport. A connection to one port was expected to carry one familiar grammar. TLS weakened that convenient inference in a useful way. Many application protocols could be protected and could share infrastructure, especially on port 443.

Sharing created an ambiguity. After TLS completed, which application protocol should consume the protected stream? A second negotiation at the application layer could answer, but it would cost another network round trip. Guessing from the port would defeat the reason for sharing it. Sending application bytes first and waiting to see which parser accepted them would make failure expensive and, in some combinations, dangerous.

ALPN moved the choice into the existing handshake. It did not require a universal application broker. It added a small exchange between the two endpoints already establishing the connection.

The historical account in RFC 8170 records the immediate pressure: HTTP/2 needed a way to negotiate its protected form without another round trip. HTTP Upgrade served the unsecured variant; ALPN became the primary mechanism for negotiating future HTTP versions over TLS. The important change was not merely speed. Protocol identity became an explicit handshake result instead of an inference made after establishment.

The client offered a set; it did not issue an order

The client's ALPN extension carries a list of opaque, non-empty protocol names. The list is ordered by client preference. That order is useful evidence of what the client would rather speak, but it is not a command to the server.

The server has its own supported set and its own preference order. It is expected to select its most preferred protocol among those the client offered. The permissible answer is therefore an intersection: the server cannot choose a protocol absent from the client's list, while the client's first entry need not defeat the server's local policy.

This arrangement divides control cleanly. The client controls the boundary of what it can parse. The server controls which mutually supported service it is willing to operate on this connection. Neither side may manufacture consent for the other.

The reply contains one protocol, not a menu. Once selected, that identifier is definitive for the connection. The server must not announce one grammar and then send application data under another. A selection is valuable precisely because it removes ambiguity before either application parser receives the stream.

No overlap was a result, not an invitation to guess

If the two supported sets do not intersect, RFC 7301 requires the server to send the fatal no_application_protocol alert. That can feel unfriendly compared with a compatibility fallback. It is actually the most truthful outcome available.

A silent fallback would leave the client unsure whether absence meant an old server, an ignored extension, a middlebox interaction or deliberate selection of some default grammar. If the endpoints then interpreted the same encrypted bytes under different protocols, the connection would be established cryptographically and broken semantically.

Failure keeps that disagreement before application data. It also makes the defect observable. Operators can distinguish “no common protocol” from certificate failure, transport loss, application rejection or an invalid first frame. A typed stop preserves the chance to change configuration or open a differently constrained connection without pretending the original one succeeded.

Later security guidance made this boundary more urgent. RFC 9325 requires modern TLS implementations to support ALPN and advises strict enforcement of the offered set and the fatal no-overlap rule. Its concern is cross-protocol confusion: data intended for one service can acquire unintended effects if another service parses it. ALPN is not a complete defence against every such attack, but accepting an unoffered protocol discards a protection the endpoints already possess.

The first design exposed its answer

RFC 7301 deliberately placed the server's selected protocol in the TLS ServerHello used at the time. That made the marker visible to network elements that differentiated treatment when a port number no longer identified the application. The document also warned that client protocol identifiers could leak sensitive information and should not be used carelessly when visible.

This was not an accidental omission from an otherwise secret mechanism. The design acknowledged its visibility instead of claiming that an encrypted application stream hid the protocol choice from the start.

TLS 1.3 changed part of that evidence surface. In RFC 8446, the client still offers ALPN in ClientHello, but the server's response appears in EncryptedExtensions, the first server message protected under handshake traffic keys. An observer's view therefore differs by TLS version and handshake path.

The safe conclusion is precise. TLS 1.3 normally protects the server's selected ALPN value at that stage. It does not make the baseline ClientHello offer disappear, and it does not justify a timeless claim that ALPN is either wholly public or wholly private.

HTTP/2 selected a grammar, then confirmed it

HTTP/2 gives the mechanism a concrete shape. RFC 9113 assigns h2 to HTTP/2 over TLS and requires protected HTTP/2 connections to use ALPN. The old h2c token describes a cleartext form and must not be sent or selected in TLS ALPN.

Yet the ALPN result is not the last word exchanged before ordinary requests. Once TLS negotiation completes, both HTTP/2 endpoints send a connection preface. The client preface begins with a deliberately recognizable octet sequence and a SETTINGS frame; the server begins with its SETTINGS frame.

Selection and confirmation do different jobs. ALPN agrees which grammar is permitted to begin. The preface proves that the following bytes actually obey that grammar and establishes its initial parameters. An operator who records only one of them loses important evidence: a selected h2 value cannot explain an invalid preface, while a captured preface without the handshake cannot show that both endpoints agreed to HTTP/2 under TLS.

Early data could not outrun a changed meaning

TLS 1.3 allows a client in eligible resumptions to send early application data before the handshake finishes. That performance feature makes ALPN's connection scope operational rather than philosophical.

Suppose early bytes were prepared under the expectation of HTTP/2, but the new connection selects another protocol. Automatically retransmitting those bytes would feed an application action into a grammar under which it was never composed. RFC 8446 therefore says a TLS implementation must not automatically resend early data unless the negotiated connection selects the same ALPN protocol.

“Same ALPN” is only a necessary boundary. It does not prove that replay is harmless, that an HTTP method is idempotent, that credentials remain appropriate or that an application operation was not already processed. Those questions belong to the application and its replay policy. ALPN prevents one particularly severe category error: carrying bytes automatically across a change in protocol meaning.

The session ticket can support resumption. It cannot certify that yesterday's application decision remains valid today.

QUIC made the choice part of transport establishment

ALPN outgrew its immediate HTTP/2 motivation. QUIC integrates TLS into a transport whose applications also need an authenticated protocol choice. RFC 9001 requires QUIC endpoints to use ALPN unless another mechanism supplies the agreement, and it requires immediate closure when no application protocol is negotiated.

QUIC adds another compatibility dimension: an application protocol may restrict which QUIC versions it can use. The server must select a protocol compatible with the client's chosen QUIC version, and either endpoint treats an incompatible result as the same no-application-protocol class of connection error.

This shows why the selection cannot be reduced to a label for traffic dashboards. It connects parsing rules to the transport instance that will carry them. A registered identifier may name HTTP/3, DNS over QUIC or another application, but the chosen name has force only because both endpoints bind it to a compatible connection before application exchange.

The registry fixed bytes, not reality

ALPN protocol names are opaque byte strings. Interoperability requires two independent implementations to use the same bytes for the same specified protocol. The current IANA TLS extension and ALPN registry provides that shared namespace under Expert Review.

The table contains familiar values such as http/1.1, h2 and h3. It also retains h2c as a reserved identifier while stating that it is not allowed in TLS ALPN. That combination is instructive: registration can preserve a name and its boundary even when one context forbids using it.

A registry row is not a deployment counter. It does not show that browsers offer the identifier, that servers select it, that traffic reaches the correct application, or that the application is secure. It proves a narrower fact: a byte sequence has an assigned description and reference, so implementers need not invent competing spellings in private.

The choice was strong because it expired

ALPN could have been designed as a remembered property of a long-lived security session. Its actual scope is more disciplined. Every new connection obtains a new offer and a new selection. A server can change its preference. A client can remove an obsolete protocol. A mixed fleet can reveal its inconsistency. A failed intersection can stop without corrupting application state.

That expiry is not wasted negotiation. It is what keeps yesterday's compatibility decision from acquiring authority over tomorrow's endpoint. The same session ticket, address and certificate can participate in another connection while the application grammar is decided again.

The Internet often reuses state to save time. Safe reuse depends on knowing which decisions may travel with that state. ALPN drew one of those lines with unusual clarity: cryptographic resumption may continue, but the protocol spoken over the new connection must still be chosen by the endpoints that will speak it.

Sources

These sources define standards, recommendations and registry state. They do not supply a current deployment share, a traffic census or proof about any particular product configuration.