HTTP/3的安全考虑应该与使用TLS的HTTP/2相当。然而，[HTTP/2] 第 10 节中的许多注意事项适用于 [QUIC-TRANSPORT]。

10.1. 服务器权限

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

10.2 跨协议攻击

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

这并不能保证免受所有跨协议攻击。我们会在[QUIC- transport]中描述一些方法，可以使用 QUIC 数据包的明文对不使用经过身份验证的传输的终端执行请求伪造的方法。

10.3. 中间封装（Intermediary-Encapsulation）攻击

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

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

10.4 推送响应的可缓存性

推送响应没有来自客户端的明确请求，请求是由服务端在PUSH_PROMISE帧中提供的。

根据原始服务器在 Cache-Control 标头字段中提供的指导，可以缓存推送的响应。但是，如果一台服务器托管多个租户，这可能会导致问题。例如，服务器可能会为多个用户提供其 URI 空间的一小部分。

当多个租户共享同一服务器上的空间时，该服务器必须确保租户无法推送他们无权访问的资源的表示。未能强制执行此操作将允许租户提供将在缓存之外提供的表示，从而覆盖权威租户提供的实际表示。

要求客户端拒绝原始服务器不具有权威性的推送响应（见第 4.6 节）。

10.5 拒绝服务注意事项

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

PUSH_PROMISE帧的数量也以类似的方式被限制。接受服务器推送的客户端应该限制一次发送的Push ID的数量。

处理能力不能像状态能力那样得到有效保护。

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

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

如果不监控此类行为的终端，则会使自己面临拒绝服务攻击。实现应该跟踪这些功能的使用，并对它们的使用设置限制。终端可以将可疑的活动视为H3_EXCESSIVE_LOAD类型的连接错误，但误报将导致中断有效连接和请求。

10.5.1 字段段大小的限制

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

终端可以使用 SETTINGS_MAX_FIELD_SECTION_SIZE（第 4.2.2 节）设置来通知对等方可能适用于字段部分大小的限制。此设置只是建议性的，因此终端可以选择发送超出此限制的字段部分，并有可能将请求或响应视为格式错误。此设置特定于 HTTP/3 连接，因此任何请求或响应都可能遇到具有较低未知限制的跃点。中间人可以尝试通过传递不同对等方提供的值来避免这个问题，但他们没有义务这样做。

当服务器接收到比它愿意处理的更大的字段段时，可以发送一个HTTP 431(请求标头字段太大)状态码([RFC6585])。客户端可以删除它无法处理的响应。

10.5.2 连接问题

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

代理还可能会在关闭携带 CONNECT 请求的流之后为 TCP 连接维护一些资源，因为传出 TCP 连接仍处于 TIME_WAIT 状态。考虑到这一点，代理可能会在 TCP 连接终止后延迟增加 QUIC 流限制一段时间。

10.6 使用压缩

当秘密数据在与攻击者控制的数据相同的上下文中被压缩时，压缩可以让攻击者恢复秘密数据。HTTP/3 启用字段压缩（第 4.2 节）；以下问题也适用于 HTTP 压缩内容编码的使用，具体请参阅 [HTTP] 的第 8.4.1 节。

有一些针对压缩的攻击利用了网络的功能(例如，[BREACH])。攻击者诱导多个包含不同明文的请求，观察每个请求中生成的密文的长度，当对秘密的猜测正确时，会显示较短的长度。

在安全通道上通信的实现不得压缩包含机密和攻击者控制的数据的内容，除非每个数据源使用单独的压缩上下文。如果不能可靠地确定数据源，则不得使用压缩。

10.7 填充和流量分析

填充可用于掩盖帧内容的确切大小，并用于缓解 HTTP 中的特定攻击，例如，压缩内容包括攻击者控制的明文和秘密数据的攻击（例如，[BREACH]）。

当HTTP/2使用填充帧和其他帧中的填充字段来使连接更能阻止流量分析时，HTTP/3既可以依赖传输层填充，也可以使用在7.2.8节和6.2.3节中讨论的保留帧和流类型。这些填充方法在填充的粒度、如何根据受保护的信息排列填充、是否在数据包丢失的情况下应用填充以及实现如何控制填充等方面产生不同的结果。

保留流类型可用于在连接空闲时提供发送流量的外观。因为HTTP流量经常以突发的形式出现，所以可以使用明显的流量来掩盖这种突发的时间或持续时间，甚至看起来像是在发送恒定的数据流。然而，由于这些流量仍然是由接收方控制的流量，如果不能及时排出这些流量并提供额外的流量控制信用，可能会限制发送方发送真实流量的能力。

为了缓解依赖于压缩的攻击，禁用或限制压缩可能比填充更可取。

填充方法的使用可能导致保护效果不如看上去那么明显。冗余填充甚至可能适得其反。充其量，填充只会使攻击者更难通过增加攻击者必须观察的帧数来推断长度信息。错误实现的填充方案很容易被绕过。特别是，具有可预测分布的随机填充提供的保护非常少。同样，将有效负载填充到固定大小会在有效负载大小跨越固定大小边界时暴露信息，如果攻击者可以控制明文，这是可能的。

10.8 帧解析

一些协议元素包含嵌套的长度元素，通常以具有显式长度的帧的形式包含可变长度整数。这可能会给粗心的实施者带来安全风险。实现必须确保帧的长度与其包含的字段长度完全匹配。

10.9 早期的数据

将 0-RTT 与 HTTP/3 一起使用会导致重放攻击。当使用带有 0-RTT 的 HTTP/3 时，必须应用 [HTTP-REPLAY] 中的反重放缓解措施。在将 [HTTP-REPLAY] 应用于 HTTP/3 时，对 TLS 层的引用是指在 QUIC 中执行的握手，而对应用程序数据的所有引用指的是流的内容。

10.10 迁移

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

10.11 隐私注意事项

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

就这些在行为上产生可观察到的差异而言，它们可以用作对特定客户进行指纹识别的基础。

HTTP/3 对使用单个 QUIC 连接的偏好允许关联用户在站点上的活动。重用不同来源的连接允许跨这些来源的活动相关联。

QUIC的几个功能要求立即响应，终端可以使用它来测量对等方的延迟，在某些情况下，这可能会出现隐私泄露。

本文档注册了一个新的 ALPN 协议 ID（第 11.1 节）并创建了管理 HTTP/3 中代码点分配的新注册表。

11.1. 注册HTTP/3标识字符串

本文在[RFC7301]建立的“TLS 应用层协议协商 (ALPN) 协议 ID”注册表中创建了一个新的HTTP/3标识注册。

“h3”字符串标识 HTTP/3；

协议：HTTP/3；

识别顺序：0x68 0x33 ("h3")；

规格：本文件；

11.2 新注册

在本文中创建的新注册按照 [QUIC-TRANSPORT] 第 22.1 节中记录的 QUIC 注册政策运行。这些注册表都包括 [QUIC-TRANSPORT] 的第 22.1.1 节中列出的通用字段集。这些注册表出现在“超文本传输协议版本3 (HTTP/3)”标题下。

这些注册表中的初始分配都被分配了永久状态，并列出了 IETF 的变更控制者和 HTTP 工作组的联系人 ([email protected])。

11.2.1 帧类型

本文为HTTP/3帧类型代码建立了一个注册表。“HTTP/3帧类型”注册表管理62位空间。本注册中心遵循QUIC注册中心政策；参见11.2节。该注册表遵循 QUIC 注册表政策；见第 11.2 节。此注册表中的永久注册是使用规范要求策略 ([RFC8126]) 分配的，但 0x00 和 0x3f 之间的值（十六进制；包括在内）除外，这些值是使用标准操作或 IESG 批准分配的，如 [ RFC8126]。

虽然此注册表与 [HTTP/2] 中定义的“HTTP/2 帧类型”注册表是分开的，但在代码空间重叠的情况下，分配最好彼此平行。如果一个条目仅存在于一个注册表中，则应尽一切努力避免将相应的值分配给不相关的操作。评审员可以拒绝与相应注册表中相同值冲突的不相关注册。

除了第11.2节中描述的常见字段外，本注册中心的永久注册必须包括以下字段：

帧类型：帧类型的名称或标签。

帧类型的规范必须包括帧布局及其语义的描述，包括有条件存在的帧的任何部分。

下表中的条目都是由本文介绍过的。

初始HTTP/3帧类型

对于 N 的非负整数值，即 0x21、0x40、...、到 0x3ffffffffffffffe，格式为 0x1f * N + 0x21 的每个代码不得由 IANA 分配，并且不得出现在分配值列表中。

11.2.2 SETTINGS参数

由于为HTTP/3设置了注册表。“HTTP/3设置”注册表管理62位空间。该注册表遵循 QUIC 注册表政策，具体见第 11.2 节。此注册表中的永久注册是使用规范要求策略 ([RFC8126]) 分配的，但 0x00 和 0x3f 之间的值（十六进制；包括在内）除外，这些值是使用标准操作或 IESG 批准分配的，如 [ RFC8126]。

虽然此注册表不同于 [HTTP/2] 中定义的“HTTP/2 设置”的注册表，但最好是这些分配彼此并行。如果一个条目仅存在于一个注册表中，则应尽一切努力避免将相应的值分配给不相关的操作。评审员可以拒绝与相应注册表中相同值冲突的不相关注册。

除了第 11.2 节中描述的通用字段外，此注册表中的永久注册必须包括以下字段：

设置名称：设置的符号名称，指定设置名称是可选的。

默认值：该设置的值，除非另有说明。默认值应该是最具限制性的值。

初始HTTP/3设置

出于格式原因，可以通过删除'SETTINGS_'前缀来简化设置名称。

对于 N 的非负整数值（即 0x21、0x40、...、到 0x3ffffffffffffffe），格式为 0x1f * N + 0x21 的每个代码不得由 IANA 分配，并且不得出现在分配值列表中。

11.2.3 错误代码

已经建立了HTTP/3错误码的注册表。“HTTP/3错误码”注册表管理一个62位的空间。该注册中心遵循QUIC注册中心政策。此注册表中的永久注册使用规范要求策略([RFC8126])分配，但 0x00 和 0x3f 之间的值（十六进制包括在内）除外，这些值是使用标准操作或 IESG 批准分配的。

错误代码的注册需要包含错误代码的描述，建议审阅者检查新注册是否可能与现有错误代码重复。鼓励使用现有注册，但不是强制性的。不鼓励使用在“HTTP/2 错误代码”注册表中注册的值，专家审阅者可能会拒绝此类注册。

除了第11.2节中描述的通用字段外，这个注册表还包括两个附加字段。在本注册中心的永久注册必须包括以下字段：

名称：错误代码的名称。

描述：错误代码语义的简要描述。

下表中的条目是本文所介绍的。这些错误代码是从对规范要求策略运行的范围中选择的，以避免与 HTTP/2 错误代码冲突。

初始 HTTP/3 错误代码

对于 N 的非负整数值（即 0x21、0x40、...、到 0x3ffffffffffffffe），格式为 0x1f * N + 0x21 的每个代码不得由 IANA 分配，并且不得出现在分配值列表中。

11.2.4 流类型

HTTP/3单向流类型会建立一个注册表，“HTTP/3流类型”注册表管理62位空间。该注册表遵循 QUIC 注册表政策；见第 11.2 节。此注册表中的永久注册是使用规范要求策略分配的，但 0x00 和 0x3f 之间的值（十六进制包括在内）除外，这些值是使用标准操作或 IESG 批准分配的。

除了第 11.2 节中描述的常见字段外，此注册表中的永久注册必须包括以下字段：

流类型：流类型的名称或标签。

发件人：HTTP/3 连接上的哪个终端可以启动这种类型的流。值为“客户端”、“服务器”或“两者都有”。

永久注册的规范必须包括流类型的描述，包括流内容的布局和语义。

下表中的初始流类型是本文出现过的：

初始流类型

对于 N 的非负整数值（即 0x21、0x40、...、到 0x3ffffffffffffffe），格式为 0x1f * N + 0x21 的每个代码不得由 IANA 分配，并且不得出现在分配值列表中。

参考及来源：https://www.rfc-editor.org/rfc/rfc9114.html

相关阅读：

HTTP3 RFC 9114 发布，深入剖析HTTP3协议（一）

HTTP3 RFC 9114 发布，深入剖析HTTP3协议（二）