Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
updated by
- rfc-8447 — IANA Registry Updates for TLS and DTLS
Extracted elements (16)
ALPN was designed to accomplish application-protocol negotiation without adding network round-trips between client and server, and was originally requested by the HTTPbis WG to support HTTP/2 negotiation over TLS, while remaining general enough for arbitrary application-layer protocols.
By managing protocol selection in the clear as part of the handshake, ALPN avoids introducing false confidence about the ability to hide the negotiated protocol. If hiding the protocol is required, renegotiation after connection establishment is the preferred methodology, as it provides true TLS security guarantees.
The ServerHello ALPN extension is sent in plaintext to permit network elements to provide differentiated service for the connection when the TCP or UDP port number is not definitive for the application-layer protocol. Placing ownership of protocol selection on the server facilitates scenarios in which certificate selection or connection rerouting may be based on the negotiated protocol.
The ALPN extension establishes properties of the connection only, not the session. When session resumption or session tickets (RFC 5077) are used, the previous contents of the ALPN extension are irrelevant; only the values in the new handshake messages are considered.
Empty strings MUST NOT be included in the ProtocolNameList, and byte strings MUST NOT be truncated. Protocols are named by IANA-registered, opaque, non-empty byte strings.
If the server supports no protocols that the client advertises, the server SHALL respond with a fatal 'no_application_protocol' alert (value 120).
The protocol identified in the ServerHello ALPN extension SHALL be definitive for the connection until renegotiated. The server SHALL NOT respond with a selected protocol and subsequently use a different protocol for application data exchange.
The ProtocolNameList in the ServerHello ALPN extension MUST contain exactly one ProtocolName, identifying the single protocol the server has selected for the connection.
The server SHOULD select the most highly preferred protocol that it supports and that is also advertised by the client. The server will ignore any protocol name it does not recognize.
A new TLS alert 'no_application_protocol' with value 120 is defined. It is a fatal alert sent by the server when no protocol advertised by the client is supported by the server.
A new TLS extension type 'application_layer_protocol_negotiation' is assigned the value 16. It may be included by the client in ClientHello and returned by the server in ServerHello to negotiate the application-layer protocol within the TLS handshake.
IANA updated the 'ExtensionType Values' registry to add entry 16 for 'application_layer_protocol_negotiation'.
This document establishes the 'Application-Layer Protocol Negotiation (ALPN) Protocol IDs' registry under the 'Transport Layer Security (TLS) Extensions' heading, operating under the Expert Review policy. Each entry requires a Protocol name, Identification Sequence (opaque byte string), and a Reference. Initial entries include HTTP/1.1, SPDY/1, SPDY/2, and SPDY/3.
In TLS versions 1.2 and below, the client sends ALPN protocol identifiers in the clear. For at least the next decade from the document's publication, browsers were expected to use these earlier TLS versions in the initial ClientHello, meaning ALPN identifiers are externally visible.
Protocol identifiers that may leak personally identifiable information, enable profiling, or leak sensitive information SHOULD NOT be used in TLS configurations where the identifier would be visible in the clear. Documents specifying such identifiers SHOULD recommend against unsafe use.
ProtocolName is an opaque byte string of length 1 to 255 bytes. ProtocolNameList is a struct containing a list of ProtocolName values with a total length of 2 to 65535 bytes, carried in the extension_data field of the ALPN extension.