广州机械网站建设,百度云网站建设教程视频,网站源码有什么用,中国四川机械加工网摘要
使用TLS早期数据会暴露出重放攻击的可能性。本文定义了允许客户端与服务器就早期数据中发送的HTTP请求进行通信的机制。描述了使用这些机制来减轻重放风险的技术。
1. 介绍
TLS 1.3[TLS13]引入了早期数据#xff08;也称为零往返时间#xff08;0-RTT#xff09;数…摘要
使用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.在判断重放风险太大的情况下服务器可以通过425Too Early状态码5.2进行响应使客户端重试单个请求而不使用早期数据。 所有这些技术都同样有效服务器可以使用最适合它的方法。
对于给定的请求对重放风险的容忍度是特定于操作的资源的因此只有源服务器知道。与使用早期数据相关的主要风险在于服务器在处理请求时采取的行动处理重复的请求可能会导致重复的效果和副作用。[TLS13]的附录E.5还描述了处理重复请求所产生的其他影响。
请求方法的安全性[RFC7231] 4.2.1是确定这一点的一种方法。然而一些资源安全的方法也会产生副作用因此这不能被普遍依赖。
建议源服务器允许资源明确配置请求中的早期数据是否合适。如果没有这些明确的信息源服务器必须拒绝早期数据或者实施本文的技术以确保在TLS握手完成之前不会处理请求。
一个请求可能会在早期数据中部分发送而请求的其余部分则在握手完成后发送。这并不一定影响对该请求的处理重要的是服务器何时开始对请求的内容采取行动。任何时候任何服务器实例都可能在握手完成之前启动处理所有服务器实例都需要考虑重放早期数据的可能性以及这可能如何影响处理见6.2。
服务器可以部分处理不完整的请求。解析头字段不执行值和确定请求路由可能不会产生副作用但其他操作可能不会。
中间服务器代理没有足够的信息来决定是否可以处理早期数据因此5.2描述了源向他们发出信号的一种方式即特定请求不适合早期数据。接受早期数据的代理必须实施这一机制。
请注意服务器不能选择在TLS层选择性地拒绝早期数据。TLS只允许服务器接受所有早期数据或不接受任何早期数据。一旦服务器决定接受早期数据它必须处理早期数据中的所有请求即使服务器通过发送425Too Early响应来拒绝请求。
服务器可以使用“early_data”TLS扩展的“max_early_data_size”字段来限制早期数据的数量。这可以避免为可能推迟到握手完成的请求提交任意数量的内存。 4. HTTP客户端使用早期数据
希望使用早期数据的客户端在发送TLS ClientHello后立即发送HTTP请求。
从本质上讲客户端可以控制是否在早期数据中发送给定的请求从而使客户端能够控制重放的风险。在没有其他信息的情况下客户端可以在早期数据可用时使用安全的HTTP方法[RFC7231]4.2.1发送请求并且不得在早期数据中发送不安全的方法或安全性未知的方法。
如果服务器拒绝TLS层的早期数据则客户端必须像新连接一样重新开始发送。这可能需要使用与早期数据乐观使用的协议不同的协商协议[ALPN]。在早期数据中发送的任何请求都需要再次发送除非客户端决定放弃这些请求。
自动重试会造成重放攻击的可能性。攻击者截获使用早期数据的连接并将早期数据复制到另一个服务器实例。第二个服务器实例接受并处理早期数据即使它不会完成TLS握手。然后攻击者允许原始连接完成。即使早期数据被检测为重复并被拒绝第一个服务器实例也可能允许连接完成。如果客户端随后重试在早期数据中发送的请求则该请求将被处理两次。如果有多个服务器实例将接受早期数据或者如果同一服务器多次接受早期数据尽管后者违反了[TLS13]第8节的要求也可以进行重放。
使用早期数据的客户端必须在收到425Too Early状态码后重试请求见5.2。
代理在转发请求时不得使用早期数据除非在前一跳中使用了早期数据或者它知道可以安全地重试请求而不会产生任何后果通常使用带外配置。在没有更好信息的情况下这意味着只有当请求以早期数据形式到达或在Early-Data头字段设置为1的情况下到达时代理才能使用早期数据见5.1。
5. HTTP早期数据扩展
由于HTTP请求可以跨越多个“跃点”因此有必要明确告知请求是否已在前一个跃点的早期数据中发送。同样当不需要早期数据时有必要有一些明确触发重试的方法。最后有必要知道客户端是否真的会执行这样的重试。
为了满足这些需求定义了两种信号机制
o Early-Data头字段包含在代理可能在完成与其客户端的TLS握手之前转发的请求中。
o 425Too 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早期数据而不是接受早期数据并选择性地处理请求。生成503Service Unavailable或425状态代码通常会导致客户端重试请求这可能会导致负载增加。 6.4. 乱序传输
在乱序传递数据的协议中如QUIC[HQ]早期数据可能在握手完成后到达。只有当服务器能够依靠其他实例正确处理相同请求的重放时服务器才可以在握手完成后处理早期数据中接收到的请求。 7. IANA考虑 本文注册了Early-Data头字段在Permanent Message Header Field NamesMessage Headers 头字段名字 Early-Data 应用协议 http 状态标准 作者IETF 标准文档本文 本文注册了425 (Too Early)状态码在HTTP Status Codeshttps://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.
