| 互联网工程任务组 (IETF) | A. Hutton |
| 请求评注: 7639 | Unify |
| 类别: Standards Track | J. Uberti |
| ISSN: 2070-1721 | |
| M. Thomson | |
| Mozilla | |
| 2015年8月 |
ALPN HTTP 头部字段
摘要
本规范允许 HTTP CONNECT 请求使用 ALPN 头部字段来指示在隧道建立后打算在隧道内使用的协议。
本备忘录的状态
这是一个互联网标准轨道文档。
本文档是互联网工程任务组 (IETF) 的产物,代表了 IETF 社区的共识。它已接受公开审查并已获得互联网工程指导组 (IESG) 批准发布。关于互联网标准的更多信息,请参阅 RFC 5741 的第2节。
有关本文档当前状态、任何勘误以及如何提供反馈的信息,可在 http://www.rfc-editor.org/info/rfc7639 获取。
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. 介绍
HTTP CONNECT 方法(RFC7231 第 4.3.6 节) 请求接收者建立到所标识源服务器的隧道,并在隧道关闭之前双向转发数据包。此类隧道通常用于通过一个或多个代理创建端到端的虚拟连接。
ALPN HTTP 头部字段用于标识客户端打算在使用 CONNECT 建立的隧道内使用的协议或协议集合。该字段使用应用层协议协商(ALPN)标识符 [RFC7301]。
对于随后使用 传输层安全(TLS) 保护的隧道,头部字段携带与 TLS 握手中所携带的应用协议标签相同的值 [RFC7301]。如果存在多个可能的应用协议,则应指示所有这些应用协议。
ALPN 头部字段仅表示客户端意图。此处使用 ALPN 标识符仅用于识别客户端打算在隧道中使用的应用协议或协议套件。该头字段不会进行协商。在 TLS 中,最终的应用协议由服务器从客户端提供的选项集中选择。其他传输层可能以不同方式协商应用协议。
代理不会实现隧道内的协议,但它们可能基于该头部字段的值做出策略决定。例如,代理可以使用应用协议来选择适当的流量优先级策略。
1.1. 需求语言
本文件中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 应按 RFC2119 中的描述来解释。
2. ALPN HTTP 头部字段
客户端在 HTTP CONNECT 请求中包含 ALPN 头部字段,以指示客户端打算在隧道内使用的应用层协议,或可能在隧道内使用的一组协议。
2.1. 头部字段值
协议字段的有效值取自由 [RFC7301] 建立的“应用层协议协商(ALPN)协议 ID”注册表 [ALPN-IDS]。
2.2. 语法
下面给出 ALPN 头部字段值的 ABNF(扩充巴科斯-诺尔范式)语法。它使用 RFC7230 第 1.2 节 中定义的语法。
ALPN = 1#protocol-id protocol-id = token ; percent-encoded ALPN protocol identifier
ALPN 协议名是八位字节序列,对格式没有额外约束。对于 tokens 中不允许的八位字节(参见 RFC7230 第 3.2.6 节),必须按照 RFC3986 第 2.1 节 的规定进行百分号编码。因此,表示百分号字符 "%"(十六进制 25)的八位字节也必须进行百分号编码。
为确保每个 ALPN 协议名有且只有一种表示方式,还适用以下附加约束:
- 如果某个八位字节是有效的 token 字符(除了 "%" 之外),则不得对其进行百分号编码。
- 在使用百分号编码时,必须使用大写十六进制数字。
在这些约束下,接收方可以使用简单的字符串比较来匹配协议标识符。
例如:
CONNECT www.example.com HTTP/1.1 Host: www.example.com ALPN: h2, http%2F1.1
2.3. 使用
在 ALPN 头部字段中使用时,ALPN 标识符用于标识整个应用协议栈,而不是单一的协议层或组件。
对于承载使用 TLS 保护的协议的 CONNECT 隧道,ALPN 头部字段的值包含将在 TLS ClientHello 消息中发送的相同 ALPN 标识符列表 [RFC7301]。
在不预期发生协议协商的情况下(例如不使用 TLS 的协议),ALPN 头部字段只包含对应于拟使用的应用协议的单个 ALPN 协议标识符。如果存在另一种可能的协议协商形式,则 ALPN 头部字段应包含可能被协商的一组协议。
代理可以使用 ALPN 头部字段的值更清晰、更高效地拒绝对 CONNECT 隧道的请求。在 HTTP 层公开协议信息允许代理更早地拒绝请求,并提供更好的错误报告(例如 403 状态码)。ALPN 头部字段可以被伪造,因此它不足以作为授权请求的充分依据。
代理可以尝试检查数据包以确定所使用的协议。这要求代理理解每个 ALPN 标识符。像 TLS 这样的协议可能会隐藏协商的协议,或者协议协商细节可能会随时间变化。因此,代理不应仅因为无法识别协议而中断 CONNECT 隧道。
代理可以使用 ALPN 头部字段值来改变其管理或优先处理连接的方式。
3. IANA 注意事项
HTTP 头部字段在由 IANA 维护的“永久消息头字段名称”注册表中注册 [MSG-HDRS]。本文档根据 RFC3864 定义并注册 ALPN 头部字段,具体如下:
- Header Field Name:
- ALPN
- Protocol:
- http
- Status:
- Standard
- Reference:
- 本文件第 2 节(RFC 7639)
- Change Controller:
- IETF (iesg@ietf.org) - Internet Engineering Task Force
4. 安全注意事项
在使用 HTTP CONNECT 连接到 TURN(Traversal Using Relays around NAT,[RFC5766])服务器的情况下,适用 RFC7231 第 4.3.6 节 中的安全注意事项。该节指出“向任意服务器建立隧道存在重大风险,特别是当目标是一个并非用于 Web 流量的知名或保留 TCP 端口时。……支持 CONNECT 的代理应将其使用限制在一组已知端口或可配置的安全请求目标白名单内。”
本文档中描述的 ALPN 头部字段是可选的。客户端和 HTTP 代理可以选择不支持它,因此要么不发送该字段,要么在存在时忽略它。如果头字段不可用或被忽略,代理就无法识别隧道的用途,并将其作为关于隧道授权决策的输入。这与客户端或代理不支持 ALPN 头字段的情况无异。
ALPN 头部字段不提供保密保护。可能暴露机密或敏感信息的 ALPN 标识符不应被发送,如 RFC7301 第 5 节 所述。
5. 参考文献
5.1. 规范性参考文献
- [RFC2119]
- Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
- [RFC3864]
- Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
- [RFC3986]
- Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
- [RFC7230]
- Fielding, R. and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
- [RFC7231]
- Fielding, R. and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
- [RFC7301]
- Friedl, S., Popov, A., Langley, A., and E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.
5.2. 信息性参考文献
- [ALPN-IDS]
- IANA, “Application-Layer Protocol Negotiation (ALPN) Protocol ID”, <http://www.iana.org/assignments/tls-extensiontype-values>.
- [MSG-HDRS]
- IANA, “Permanent Message Header Field Names>”, <https://www.iana.org/assignments/message-headers>.
- [RFC5246]
- Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
- [RFC5766]
- Mahy, R., Matthews, P., and J. Rosenberg, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)”, RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
- [TRAFFIC]
- Pironti, A., Strub, P-Y., and K. Bhargavan, “Identifying Website Users by TLS Traffic Analysis: New Attacks and Effective Countermeasures, Revision 1”, 2012, <https://alfredo.pironti.eu/research/publications/full/identifying-website-users-tls-traffic-analysis-new-attacks-and-effective-counterme>.