RFC8470在HTTP中使用早期数据

摘要

使用TLS早期数据会暴露出重放攻击的可能性。本文定义了允许客户端与服务器就早期数据中发送的HTTP请求进行通信的机制。描述了使用这些机制来减轻重放风险的技术。

1.  介绍

TLS 1.3[TLS13]引入了早期数据（也称为零往返时间（0-RTT）数据）的概念。如果客户端最近与同一服务器通信，早期数据允许客户端在连接的第一次往返中向服务器发送数据，而无需等待TLS握手完成。

当与HTTP[HTTP]一起使用时，早期数据允许客户端立即发送请求，从而避免TLS握手所需的一到两次往返延迟。这是一个显著的性能提升；然而，它有很大的局限性。

使用早期数据的主要风险是，攻击者可能会捕获并重放其中包含的请求。TLS[TLS13]描述了可以用来降低攻击者成功重放请求的可能性的技术，但这些技术可能很难部署，并且仍然会留下一些成功攻击的可能性。

请注意，这与自动重试或用户发起的重试不同；重放是由攻击者在客户端不知情的情况下发起的。为了帮助降低HTTP中重放的风险，本文概述了在服务器中控制这些风险的技术，并定义了在早期数据中发送请求时客户端的要求。

本文中的建议也适用于在QUIC[HQ]上的HTTP中使用0-RTT。

2.  HTTP中的早期数据

从概念上讲，早期数据与其他应用数据拼接在一起，形成单个流。这可能意味着请求完全包含在早期数据中，或者请求中只有一部分是早期的。在复用协议中，如HTTP/2[RFC7540]或HTTP/QUIC[HQ]，多个请求可能在早期数据中部分传递。

本文假设的模型是，一旦TLS握手完成，在该TLS连接上接收的早期数据就不会是该数据的重放副本。然而，需要注意的是，这并不意味着早期数据不会或没有在另一个连接上重放。

3.  HTTP服务器支持早期数据

服务器决定在发送TLS会话票据时是否向客户端提供在未来连接上发送早期数据的能力。

TLS[TLS13]要求使用重放检测策略，以降低攻击者成功重放早期数据的能力。这些反重放技术减少了但并没有完全消除数据被重放的机会，并确定了重放次数的固定上限。

当服务器启用早期数据时，可以使用许多技术来降低重放风险：  

1.服务器可以拒绝TLS层的早期数据。服务器不能选择性地拒绝早期数据，因此这会导致在早期数据中发送的所有请求都被丢弃。

2.服务器可以选择将早期数据的处理延迟到TLS握手完成之后。通过延迟处理，它可以确保其中的请求只使用成功完成的连接。这为服务器提供了一些保证，即早期数据不会被重放。如果服务器在早期数据中接收到多个请求，它可以根据每个请求确定是否推迟HTTP处理。

3.在判断重放风险太大的情况下，服务器可以通过425（Too Early）状态码（5.2）进行响应，使客户端重试单个请求，而不使用早期数据。

所有这些技术都同样有效；服务器可以使用最适合它的方法。

对于给定的请求，对重放风险的容忍度是特定于操作的资源的（因此只有源服务器知道）。与使用早期数据相关的主要风险在于服务器在处理请求时采取的行动；处理重复的请求可能会导致重复的效果和副作用。[TLS13]的附录E.5还描述了处理重复请求所产生的其他影响。

请求方法的安全性（[RFC7231] 4.2.1）是确定这一点的一种方法。然而，一些资源安全的方法也会产生副作用，因此这不能被普遍依赖。

建议源服务器允许资源明确配置请求中的早期数据是否合适。如果没有这些明确的信息，源服务器必须拒绝早期数据，或者实施本文的技术，以确保在TLS握手完成之前不会处理请求。

一个请求可能会在早期数据中部分发送，而请求的其余部分则在握手完成后发送。这并不一定影响对该请求的处理；重要的是服务器何时开始对请求的内容采取行动。任何时候，任何服务器实例都可能在握手完成之前启动处理，所有服务器实例都需要考虑重放早期数据的可能性，以及这可能如何影响处理（见6.2）。

服务器可以部分处理不完整的请求。解析头字段（不执行值）和确定请求路由可能不会产生副作用，但其他操作可能不会。

中间服务器（代理）没有足够的信息来决定是否可以处理早期数据，因此5.2描述了源向他们发出信号的一种方式，即特定请求不适合早期数据。接受早期数据的代理必须实施这一机制。

请注意，服务器不能选择在TLS层选择性地拒绝早期数据。TLS只允许服务器接受所有早期数据或不接受任何早期数据。一旦服务器决定接受早期数据，它必须处理早期数据中的所有请求，即使服务器通过发送425（Too Early）响应来拒绝请求。

服务器可以使用“early_data”TLS扩展的“max_early_data_size”字段来限制早期数据的数量。这可以避免为可能推迟到握手完成的请求提交任意数量的内存。

  

4.  HTTP客户端使用早期数据

希望使用早期数据的客户端在发送TLS ClientHello后立即发送HTTP请求。

从本质上讲，客户端可以控制是否在早期数据中发送给定的请求，从而使客户端能够控制重放的风险。在没有其他信息的情况下，客户端可以在早期数据可用时使用安全的HTTP方法（[RFC7231]，4.2.1）发送请求，并且不得在早期数据中发送不安全的方法（或安全性未知的方法）。

如果服务器拒绝TLS层的早期数据，则客户端必须像新连接一样重新开始发送。这可能需要使用与早期数据乐观使用的协议不同的协商协议[ALPN]。在早期数据中发送的任何请求都需要再次发送，除非客户端决定放弃这些请求。

自动重试会造成重放攻击的可能性。攻击者截获使用早期数据的连接，并将早期数据复制到另一个服务器实例。第二个服务器实例接受并处理早期数据，即使它不会完成TLS握手。然后，攻击者允许原始连接完成。即使早期数据被检测为重复并被拒绝，第一个服务器实例也可能允许连接完成。如果客户端随后重试在早期数据中发送的请求，则该请求将被处理两次。如果有多个服务器实例将接受早期数据，或者如果同一服务器多次接受早期数据（尽管后者违反了[TLS13]第8节的要求），也可以进行重放。

使用早期数据的客户端必须在收到425（Too Early）状态码后重试请求（见5.2）。

代理在转发请求时不得使用早期数据，除非在前一跳中使用了早期数据，或者它知道可以安全地重试请求而不会产生任何后果（通常使用带外配置）。在没有更好信息的情况下，这意味着只有当请求以早期数据形式到达或在Early-Data头字段设置为1的情况下到达时，代理才能使用早期数据（见5.1）。

5.  HTTP早期数据扩展

由于HTTP请求可以跨越多个“跃点”，因此有必要明确告知请求是否已在前一个跃点的早期数据中发送。同样，当不需要早期数据时，有必要有一些明确触发重试的方法。最后，有必要知道客户端是否真的会执行这样的重试。

为了满足这些需求，定义了两种信号机制：

o Early-Data头字段包含在代理可能在完成与其客户端的TLS握手之前转发的请求中。

o 425（Too Early）状态码是为服务器定义的，用于指示由于可能的重放攻击的后果而无法处理请求。

它们旨在更好地协调用户代理和源服务器之间的早期数据使用，以及在存在网关（也称为“反向代理”、“内容交付网络”或“代理”）时。

网关通常没有关于在早期数据中发送给定请求时是否可以安全处理的特定信息。在许多情况下，只有源服务器有必要的信息决定重放的风险是否可接受。这些扩展允许网关与源服务器之间进行协调。

5.1. Early-Data头字段

Early-Data请求头字段指示该请求已经在早期数据中被传送，并且客户端理解425态码。

它只有一个有效值：1。其语法由以下ABNF[ANDF]定义：

   Early-Data = "1"

   例如：

      GET /resource HTTP/1.0

      Host: example.com

      Early-Data: 1

    在完成与其客户端的TLS握手之前转发请求的代理必须在发送请求时将Early Data头字段设置为1（即，如果请求中不存在，则添加该字段）。如果请求可能已经被重放，并且可能已经被它或另一个实例转发，则代理必须使用早期数据头字段（见6.2）。

如果请求中存在此头字段，则代理不得删除该头字段。早期数据不得出现在Connection头字段中。

Early Data头字段不适用于用户代理（即请求的原始发起方）。在早期数据中发送请求意味着客户端理解该规范并且愿意响应425状态码重试请求。在早期数据中发送请求的用户代理不需要包括Early-Data头字段。

服务器无法通过等待握手完成来确保包含Early Data头字段的请求可以安全处理。在上一个跃点的Early-Data中发送了标记为早期数据的请求。必须使用425状态代码拒绝包含Early-Data头字段且无法安全处理的请求。

Early-Data头字段携带一位信息，客户端最多必须包含一个实例。服务器必须将头字段的多个或无效实例视为等效于值为1的单个实例。Early-Data头字段不得包含在响应或请求trailers中。

5.2.  425 (Too Early)状态码

425（太早）状态码表示服务器不愿意冒险处理可能被重放的请求。

期望在早期数据中发送请求的用户代理在接收425响应状态码时重试该请求。用户代理应该自动重试，但任何重试都不能在早期数据中发送。

在所有情况下，代理都可以转发425状态码。如果代理接收和转发的请求包含Early-Data头字段，则代理必须转发425状态码。否则，接收早期数据中的请求的代理可以响应425（状态码自动重试该请求，但它必须等待TLS握手在其接收到请求的连接上完成。

服务器不能假设客户端能够重试请求，除非在早期数据中收到请求或Early-Data头字段设置为1。除非满足其中一个条件，否则服务器不应发出425状态码。

默认情况下，425状态码不可缓存。其有效载荷不是任何已识别资源的表示。

6.  安全考虑

使用早期数据会使客户端面临其请求被重放的风险。重试或重放的请求可能会在服务器上产生不同的副作用。除了这些副作用之外，重放和重试还可以用于流量分析，以恢复有关请求或这些请求所针对的资源的信息。特别是，重放的请求可能会导致不同的响应，即使内容仍然保密，从受保护数据的长度来看，这可能是可以观察到的。

6.1.  网关和早期数据

网关不得转发早期数据中接收到的请求，除非它知道源服务器了解Early-Data头字段并将正确生成425状态码。不确定源服务器是否支持该请求的早期数据的网关应该延迟转发请求，直到与其客户端的TLS握手完成，或者发送425状态码作为响应。

一个网关如果没有至少一个支持Early-Data头字段的潜在源服务器，则需要花费大量精力才能从启用早期数据中获得适度的性能优势。如果没有源服务器支持早期数据，那么完全禁用早期数据会更有效。

6.2.  早期数据的一致处理

对到达早期数据或部分到达早期数据的请求进行一致处理对于避免对重放的请求进行不适当的处理至关重要。如果在TLS握手完成之前处理请求不安全，则服务器的所有实例（包括网关）都需要同意并拒绝请求或延迟处理。

禁用早期数据、延迟请求或拒绝425状态码的请求，都是缓解重放攻击的良好措施。服务器实例可以实现这些措施中的任何一个，并且是一致的，即使不同的实例使用不同的方法。至关重要的是，这意味着可以采用不同的缓解措施来应对其他情况，例如服务器负载（server load）。

如果服务器和任何其他服务器实例可能对如何处理相同的数据做出不同的决定，则在握手完成之前，服务器不得对早期数据采取行动。  

6.3.  拒绝服务

接受早期数据会导致重放处理成本高昂的请求，使服务器面临潜在的拒绝服务风险。负载下的服务器应该更喜欢整体拒绝TLS早期数据，而不是接受早期数据并选择性地处理请求。生成503（Service Unavailable）或425状态代码通常会导致客户端重试请求，这可能会导致负载增加。

6.4.  乱序传输

在乱序传递数据的协议中（如QUIC[HQ]），早期数据可能在握手完成后到达。只有当服务器能够依靠其他实例正确处理相同请求的重放时，服务器才可以在握手完成后处理早期数据中接收到的请求。

7.  IANA考虑

   本文注册了Early-Data头字段，在"Permanent Message Header Field Names"（Message Headers）

   头字段名字：  Early-Data

   应用协议： http

   状态：标准

   作者：IETF

   标准文档：本文 

   

   本文注册了425 (Too Early)状态码，在"HTTP Status Codes"（https://www.iana.org/assignments/http-status-codes）.

   值： 425

   描述： Too Early 

   Reference:  本文

8.  参考文档

8.1.  标准文献

[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <Information on RFC 5234 » RFC Editor>.

[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing",RFC 7230, DOI 10.17487/RFC7230, June 2014, <Information on RFC 7230 » RFC Editor>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,DOI 10.17487/RFC2119, March 1997, <Information on RFC 2119 » RFC Editor>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231,DOI 10.17487/RFC7231, June 2014, <Information on RFC 7231 » RFC Editor>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174,DOI 10.17487/RFC8174, May 2017, <Information on RFC 8174 » RFC Editor>.

[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,<Information on RFC 8446 » RFC Editor>.

8.2.  参考性文献

[ALPN] 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, <Information on RFC 7301 » RFC Editor>.

[HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over QUIC", Work in Progress, draft-ietf-quic-http-14, August 2018.

[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <Information on RFC 7540 » RFC Editor>.