10. Security Considerations (安全考虑)

HTTP/3的安全考虑应该与带TLS的HTTP/2相当。然而，[HTTP/2] 第10节中的许多考虑适用于 [QUIC-TRANSPORT] 并在该文档中讨论。

10.1. Server Authority (服务器权威)

HTTP/3依赖于HTTP的权威定义。建立权威的安全考虑在 [HTTP] 的第17.1节中讨论。

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

在TLS和QUIC握手中使用ALPN在处理应用层字节之前建立目标应用协议。这确保端点有强有力的保证，对等方正在使用相同的协议。

这不能保证免受所有跨协议攻击。[QUIC-TRANSPORT] 的第21.5节描述了QUIC数据包明文可以用于对不使用经过身份验证的传输的端点执行请求伪造的一些方式。

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

HTTP/3字段编码允许表达在HTTP使用的语法中无效的字段名称（[HTTP] 的第5.1节）。包含无效字段名称的请求或响应必须 (MUST) 被视为格式错误。因此，中介不能将包含无效字段名称的HTTP/3请求或响应转换为HTTP/1.1消息。

同样，HTTP/3可以传输无效的字段值。虽然大多数可以编码的值不会改变字段解析，但如果逐字翻译回车符（ASCII 0x0d）、换行符（ASCII 0x0a）和空字符（ASCII 0x00），攻击者可能会利用它们。包含字段值中不允许的字符的任何请求或响应必须 (MUST) 被视为格式错误。有效字符由 [HTTP] 第5.5节中的"field-content" ABNF规则定义。

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

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

基于源服务器在Cache-Control头字段中提供的指导，可以缓存推送的响应。但是，如果单个服务器承载多个租户，这可能会导致问题。

当多个租户共享同一服务器上的空间时，该服务器必须 (MUST) 确保租户无法推送他们没有权限的资源的表示。未能强制执行这一点将允许租户提供一个将从缓存中提供的表示，覆盖权威租户提供的实际表示。

客户端必须拒绝源服务器不具有权威性的推送响应；参见第4.6节。

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

HTTP/3连接可能需要比HTTP/1.1或HTTP/2连接更大的资源承诺才能运行。字段压缩和流量控制的使用依赖于存储更大量状态的资源承诺。这些功能的设置确保这些功能的内存承诺是严格限制的。

PUSH_PROMISE帧的数量以类似的方式受到约束。接受服务器推送的客户端应该 (SHOULD) 限制它一次发出的推送ID数量。

处理能力不能像状态容量那样有效地保护。

发送对等方需要忽略的未定义协议元素的能力可能被滥用，导致对等方花费额外的处理时间。这可能通过设置多个未定义的SETTINGS参数、未知帧类型或未知流类型来完成。但是请注意，某些用途是完全合法的，例如可选理解的扩展和填充以增加对流量分析的抵抗力。

字段段的压缩也提供了一些浪费处理资源的机会；有关潜在滥用的更多详细信息，请参见 [QPACK] 的第7节。

所有这些功能——即服务器推送、未知协议元素、字段压缩——都有合法用途。这些功能只有在不必要地或过度使用时才会成为负担。

不监控此类行为的端点会面临拒绝服务攻击的风险。实现应该 (SHOULD) 跟踪这些功能的使用并设置其使用限制。端点可以 (MAY) 将可疑活动视为类型为H3_EXCESSIVE_LOAD的连接错误，但误报将导致中断有效的连接和请求。

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

大的字段段（第4.1节）可能导致实现承诺大量状态。对于路由至关重要的头字段可能出现在头段的末尾，这会阻止将头段流式传输到其最终目的地。这种排序和其他原因（例如确保缓存正确性）意味着端点可能需要缓冲整个头段。由于字段段的大小没有硬性限制，某些端点可能被迫为头字段承诺大量可用内存。

端点可以使用SETTINGS_MAX_FIELD_SECTION_SIZE（第4.2.2节）设置来建议对等方可能适用于字段段大小的限制。此设置仅是建议性的，因此端点可以 (MAY) 选择发送超过此限制的字段段，并冒着请求或响应被视为格式错误的风险。

接收到大于其愿意处理的字段段的服务器可以发送HTTP 431（Request Header Fields Too Large）状态码 ([RFC6585])。客户端可以丢弃它无法处理的响应。

10.5.2. CONNECT Issues (CONNECT问题)

CONNECT方法可用于在代理上创建不成比例的负载，因为与TCP连接的创建和维护相比，流创建相对便宜。因此，支持CONNECT的代理在接受的同时请求数量上可能会更加保守。

代理还可能在携带CONNECT请求的流关闭后为TCP连接维护一些资源，因为传出的TCP连接保持在TIME_WAIT状态。为此，代理可能会在TCP连接终止后的一段时间内延迟增加QUIC流限制。

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

当压缩在与攻击者控制的数据相同的上下文中时，压缩可以允许攻击者恢复秘密数据。HTTP/3启用字段压缩（第4.2节）；以下关注点也适用于HTTP压缩内容编码的使用；参见 [HTTP] 的第8.4.1节。

有可证明的压缩攻击利用了网络的特性（例如 [BREACH]）。攻击者引发包含不同明文的多个请求，观察每个结果密文的长度，当对秘密的猜测正确时会显示更短的长度。

在安全通道上通信的实现禁止 (MUST NOT) 压缩包含机密和攻击者控制的数据的内容，除非对每个数据源使用单独的压缩上下文。如果无法可靠地确定数据源，则禁止 (MUST NOT) 使用压缩。

有关字段段压缩的进一步考虑在 [QPACK] 中描述。

10.7. Padding and Traffic Analysis (填充和流量分析)

填充可用于模糊帧内容的确切大小，并提供以减轻HTTP中的特定攻击，例如压缩内容包括攻击者控制的明文和秘密数据的攻击（例如 [BREACH]）。

HTTP/2使用PADDING帧和其他帧中的Padding字段使连接对流量分析更具抵抗力，HTTP/3可以依赖传输层填充或使用第7.2.8节和第6.2.3节中讨论的保留帧和流类型。这些填充方法在填充的粒度、填充相对于受保护信息的排列方式、在数据包丢失的情况下是否应用填充以及实现如何控制填充方面产生不同的结果。

保留流类型可用于在连接空闲时给出发送流量的外观。因为HTTP流量通常以突发方式发生，表面流量可用于模糊此类突发的时间或持续时间，甚至到看起来发送恒定数据流的程度。但是，由于此类流量仍然受到接收方的流量控制，未能及时排空此类流并提供额外的流量控制信用可能会限制发送方发送真实流量的能力。

为了减轻依赖压缩的攻击，禁用或限制压缩作为对策可能比填充更可取。

10.8. Frame Parsing (帧解析)

几个协议元素包含嵌套长度元素，通常以具有显式长度的帧形式包含可变长度整数。这可能对粗心的实现者构成安全风险。实现必须 (MUST) 确保帧的长度与它包含的字段的长度完全匹配。

10.9. Early Data (早期数据)

使用0-RTT的HTTP/3会产生重放攻击的暴露。使用HTTP/3与0-RTT时必须 (MUST) 应用 [HTTP-REPLAY] 中的防重放缓解措施。

10.10. Migration (迁移)

某些HTTP实现使用客户端地址进行日志记录或访问控制目的。由于QUIC客户端的地址可能在连接期间更改（并且未来版本可能支持同时使用多个地址），此类实现需要在相关时主动检索客户端的当前地址，或明确接受原始地址可能更改。

10.11. Privacy Considerations (隐私考虑)

HTTP/3的几个特征为观察者提供了随时间关联单个客户端或服务器操作的机会。这些包括设置值、对刺激的反应时间以及对由设置控制的任何功能的处理。

就这些创建行为中的可观察差异而言，它们可以用作指纹识别特定客户端的基础。

HTTP/3倾向于使用单个QUIC连接允许关联用户在站点上的活动。为不同来源重用连接允许关联这些来源之间的活动。