Skip to main content

10. Security Considerations (安全考虑)

10.1. Server Authority (服务器权威性)​

HTTP/2 依赖 HTTP/1.1 对服务器权威性的定义（参见 [HTTP] 的 Section 17.1）。这依赖于传输层的"安全"属性（如 [HTTP] 的 Section 4.2.2 中定义的那样）。用于建立权威性的备用服务（[ALT-SVC]）可能引入相当大的额外复杂性。

10.2. Cross-Protocol Attacks (跨协议攻击)​

在 TLS 中，HTTP/2 使用应用层协议协商 (ALPN) 扩展 [TLS-ALPN] 来协商协议的使用。这创建了一个正向信号，表明服务器支持 HTTP/2，并减少了 HTTP/2 对跨协议攻击的暴露。

然而，在不使用 TLS 或其中未使用 ALPN 的情况下，HTTP/2 的客户端连接前言（Section 3.4）可能与其他协议混淆。HTTP/2 连接前言旨在通过选择不太可能作为其他协议有效开头的序列来最小化这种可能性。

任何对 HTTP/2 端点可访问的协议都可以用于建立看似有效的 HTTP/2 连接。为此，服务器端点接收到的连接前言需要对协议有效，才能形成跨协议攻击。

客户端连接前言（Section 3.4）不足以保证协议没有混淆，但它提供了某些保护。HTTP/2 客户端实现可能还需要在应用 HTTP 语义之前进行额外的检查。具体而言，客户端需要确保初始响应是对客户端发送的消息的合法响应。

服务器可能通过向目标服务器发送客户端想要发送到其他服务器的请求来攻击客户端。如果接收服务器支持除 HTTP/2 之外的 HTTP 方案，则服务器可以读取和回显发送到其他服务器的请求。攻击者可以拦截并修改客户端接收到的响应，从而导致客户端将响应中的信息与对它不属于的请求的响应关联起来。

10.3. Intermediary Encapsulation Attacks (中介体封装攻击)​

HTTP/2 字段编码允许在字段名称和值中表达本身无效的字段名称和值，或在 HTTP/1.1 中无法表达的字段名称和值。对字段名称和值的接受或使用不足的验证的请求或响应可能使攻击者能够使用中介体封装请求或响应，使得无效的消息看起来有效。

不完全验证请求和响应的 HTTP/2 到 HTTP/1.1 转换器可能允许恶意客户端走私字段值或创建带有误导性字段名称的字段。

10.4. Cacheability of Pushed Responses (推送响应的可缓存性)​

推送响应没有来自客户端的显式请求；请求由服务器在 PUSH_PROMISE 帧中提供。

缓存推送响应可能存在问题。根据用于建立连接的信息，推送响应可能无意中对新客户端可用，该客户端共享连接但无意中请求该资源。

例如，在使用 TLS 进行身份验证的情况下，恶意客户端可能使用相同的连接接收有关已验证用户的敏感信息的推送响应。

服务器必须 (MUST) 仅在可缓存的请求中包含值（参见 [HTTP] 的 Section 9.2.3）；推送请求不包括请求内容的值。推送响应通过包含 Cache-Control 字段中的 no-cache 或 private 缓存响应指令来标记为不可缓存（参见 [HTTP-CACHING] 的 Section 5.2.2.4）。

如果可以为可缓存和不可缓存的响应提供相同的推送响应，则客户端可能会使用可缓存的响应来错误地缓存推送响应。

因此，服务器应该 (SHOULD) 在推送流的 HEADERS 帧中包含具有值 "no-cache" 的 Cache-Control 字段，除非另有显式信号表明客户端正在缓存该响应。

10.5. Denial-of-Service Considerations (拒绝服务考虑)​

HTTP/2 的使用引入了几个新的拒绝服务 (DoS) 机会。

10.5.1. Limits on Field Section Size (字段部分大小限制)​

包含大量字段或长字段名称或值的字段部分可能会导致实现消耗过多的内存、CPU 时间或两者。

实现应该 (SHOULD) 对接受的字段行的总数和大小以及发送的总数和大小施加限制，从而限制形成字段部分的帧的总大小。服务器可能希望维护字段行的白名单，客户端可能想要拒绝字段行，但两者都应该 (SHOULD) 记录并考虑可能妨碍互操作性的限制。

10.5.2. CONNECT Issues (CONNECT问题)​

CONNECT 方法可用于为不受信任的目的地创建连接。CONNECT 的 TCP 连接不受控制，可能会尝试连接到端点或其他设备，从而造成连接洪水。实现应该 (SHOULD) 对被允许作为 CONNECT 目标的目的地设置限制，并且应该 (SHOULD) 记录这些限制。

10.5.3. Use of Compression (压缩的使用)​

HTTP/2 中字段块的压缩依赖于可以被攻击者用来导致拒绝服务的算法和状态。

攻击者可以发送带有精心制作的字段的请求，以创建需要大量解码器资源的字段部分。这可以通过使用大量的 Huffman 编码字符串或大量的更新动态表来实现。终止字段部分后立即开始新的字段部分（例如，在空的 DATA 帧后跟随 HEADERS 帧）也可能被用来限制解码器资源的可用性。

类似的攻击可以通过攻击性地使用字段部分的压缩状态来发送，以创建需要大量的编码器资源的响应。

实现应该 (SHOULD) 对它们解压缩的字段的大小设置限制。

10.5.4. Use of Flow Control (流量控制的使用)​

HTTP/2 中的流量控制允许对手限制对等方可以发送的数据量。窗口更新的实现或流量控制窗口的管理可能导致流无法获得可用的窗口，从而使流无法进行。

10.5.5. Use of Settings (设置的使用)​

SETTINGS 帧可能被用于使对等方消耗额外的处理时间。这可能通过频繁改变设置、在不改变任何设置的情况下发送 SETTINGS 帧、或频繁改变设置来实现。

其他限制值的 SETTINGS 参数可能被用来消耗资源，例如通过设置非常小的 SETTINGS_HEADER_TABLE_SIZE 参数值来禁用 HPACK 的动态表。

终端应该 (SHOULD) 检测这些行为，并将其视为 ENHANCE_YOUR_CALM 类型的连接错误（Section 5.4.1）。

10.5.6. Use of Priorities (优先级的使用)​

优先级可能被用于使对等方消耗过多的资源。优先级树的频繁改变或不合理的复杂度都可能导致消耗过多的 CPU 资源。

10.5.7. Use of HTTP/2 Without TLS (不使用TLS的HTTP/2)​

HTTP/2 可以在不使用 TLS 的情况下部署。这种模式对某些攻击具有与 HTTP/1.1 相同的漏洞。将使用这种操作模式的实现应该 (SHOULD) 适用于 HTTP/1.1 的保护措施。

实现还需要意识到许多 HTTP/2 功能在没有 TLS 的情况下可能更容易受到攻击。特别地，由于 TLS 提供的机密性保护和完整性保护的缺失，数据的加密或完整性受到威胁。

10.6. Use of Compression (压缩的使用)​

压缩可能允许攻击者恢复加密通信的秘密内容，当该压缩与攻击者控制的数据以及攻击者可以观察传输大小的秘密数据组合时。

HTTP/2 在几个地方提供了压缩：字段块中使用 HPACK [COMPRESSION]，以及 DATA 帧的内容可以使用内容编码（参见 [HTTP] 的 Section 8.4.1）。

HPACK 旨在更难利用秘密的披露；但是，在某些情况下，实现选择或应用程序可以实现的其他保护措施的权衡是不完美的。攻击可能利用多个请求之间的字段压缩状态的重用。实现和应用程序可以选择限制跨请求的压缩状态的使用量以提高保护，但以增加消息的大小为代价。

通常认为压缩 DATA 帧中的内容较安全，因为 DATA 帧中的内容不太可能与跨多个请求的攻击者控制的数据混合。然而，压缩内容编码会合并来自不同源的信息。尽管使用不同源标识符区分不同来源的信息（参见 [HTTP] 的 Section 11.5），但压缩可以删除这些分隔符，如 [BREACH] 中所述。

通常认为为内容编码禁用或限制压缩对于减轻这些攻击是充分的，但这可能不足以阻止所有攻击。

10.7. Use of Padding (填充的使用)​

填充可以用来隐藏帧和消息内容的确切大小。填充可用于减轻攻击，这些攻击依赖于使用流量分析来推断有关消息的信息，这对 HTTP 有特别的重要性，其中压缩消息的长度可能揭示有关所包含内容的信息。

使用填充的一个例子是，发送大量的 HEADERS 和 DATA 帧，它们的有效负载大小在帧之间有所不同以便隐藏消息的确切大小。使用填充可以减少某些攻击（例如 [BREACH]）。

一般而言，流量分析攻击的存在意味着为每个字段或帧填充到固定的大小不足以提供保护。为了效率和一定程度的保护，应该 (SHOULD) 随机选择填充的大小。

填充不是隐藏消息大小的完美保护。攻击者可能能够利用关于消息大小的统计数据，这可能使攻击者能够利用消息的长度，无论是否填充，以某种概率推断内容的信息。

10.8. Privacy Considerations (隐私考虑)​

HTTP/2 的若干特性为观察者提供了关联一组请求的机会。这包括设置的值、帧的压缩上下文、流量控制窗口的管理以及消息到达的时间。

特别是，包含关于用户身份的信息的 HTTP 字段可能与其他通信关联，即使使用不同的服务器。

HTTP/2 不提供特定的机制来保护用户隐私。

第10章完成！

References​

  • [HTTP] RFC 9110
  • [HTTP-CACHING] RFC 9111
  • [TLS-ALPN] RFC 7301
  • [ALT-SVC] RFC 7838
  • [COMPRESSION] RFC 7541
  • [BREACH] "BREACH: Reviving the CRIME Attack"
Last updated on