rfc-7639

The ALPN HTTP Header Field

A. Hutton, J. Uberti, M. Thomson

date2015-08 streamIETF areawit wghttpbis statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc7639 doi10.17487/RFC7639

This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.

Extracted elements (13)

design-rationale §2.3

Exposing protocol information at the HTTP layer via the ALPN header allows a proxy to deny CONNECT requests earlier and with better error reporting (e.g., a 403 status code), rather than requiring packet inspection after the tunnel is established.

http

design-rationale §1

The ALPN header field carries an indication of client intent only and no negotiation takes place using it. In TLS, the final application protocol choice is made by the server from the set presented by the client; the header field merely signals what the client expects to use.

http, tls

interoperability-note §2.3

For a CONNECT tunnel conveying a TLS-secured protocol, the value of the ALPN header field MUST contain the same list of ALPN identifiers that will be sent in the TLS ClientHello message. For protocols without negotiation, a single ALPN identifier is used.

http, tls

interoperability-note §4

The ALPN header field is OPTIONAL; clients and HTTP proxies may choose not to support it. If absent or ignored, a proxy cannot identify the tunnel's intended protocol, which is indistinguishable from the case where either party does not support the field.

http

normative-requirement §2.2 MUST NOT

Octets in the ALPN protocol MUST NOT be percent-encoded if they are valid token characters except '%'. When using percent-encoding, uppercase hex digits MUST be used. These constraints ensure precisely one canonical representation for any ALPN protocol name.

http

normative-requirement §2.3 SHOULD NOT

Proxies SHOULD NOT break a CONNECT tunnel solely on the basis of a failure to recognize the protocol indicated in the ALPN header field, since protocols like TLS can hide negotiated protocols and negotiation details may change over time.

http, tls

protocol-element §2

The ALPN HTTP header field is included in an HTTP CONNECT request to indicate the application-layer protocol(s) a client intends to use within the established tunnel. It uses ALPN protocol identifiers as defined in RFC 7301.

http, tls

protocol-element §2.1

Valid values for the ALPN header field's protocol-id are taken from the IANA 'Application-Layer Protocol Negotiation (ALPN) Protocol ID' registry established by RFC 7301.

http, registry, tls

registry §3

This document registers the 'ALPN' header field in the IANA 'Permanent Message Header Field Names' registry. Protocol: http; Status: Standard; Reference: Section 2 of RFC 7639; Change Controller: IETF.

http, registry

security-consideration §4 SHOULD

Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets, due to significant risks in establishing tunnels to arbitrary servers, particularly to well-known or reserved TCP ports.

http, security

security-consideration §4

The ALPN header field value can be falsified by a client. If tunnel data is encrypted (e.g., with TLS), the proxy may be unable to verify the claimed protocol, meaning a proxy cannot rely solely on the ALPN header field value as a policy input in all cases.

http, security, tls

security-consideration §4 SHOULD NOT

There is no confidentiality protection for the ALPN header field. ALPN identifiers that might expose confidential or sensitive information SHOULD NOT be sent, as described in Section 5 of RFC 7301.

http, security, privacy, tls

wire-format §2.2

The ALPN header field syntax is defined as `ALPN = 1#protocol-id` where `protocol-id = token`. Octets not allowed in tokens MUST be percent-encoded per RFC 3986 Section 2.1, and the percent character '%' (hex 25) MUST itself be percent-encoded.

http