HTTP/3协议的安全优势与挑战

Posted 2021-04-26 FreeBuf

HTTP/3是超文本传输协议（HTTP）的第三个正式版本，将改善网络性能和稳定性，解决各种安全隐私问题，但尽管如此，仍存在一些安全挑战。

HTTP/3不再使用传输控制协议（TCP），相反，将使用2012年谷歌提出的QUIC传输协议。实际上，HTTP/3前身是HTTP-over-QUIC。

2018年10月，互联网工程任务组（IETF） HTTP和QUIC工作组主席Mark Nottingham提出了将HTTP-over-QUIC更名为HTTP/3

QUIC是基于用户数据包协议（UDP）连接的复用版本的传输层协议。与TCP不同，UDP不遵循TCP三向交握，而是使用单个UDP往返。因此，在用户代理和Web服务器之间的每个连接都使用UDP，QUIC协议极大地改善了任何web组件的网络性能。

同样，QUIC依靠多路复用来在单个连接上无缝地管理用户代理与服务器之间的多个交互，而没有一个阻塞另一个，因此与以前的版本相比，有助于提高性能。从性能和稳定性的角度考虑，HTTP/3似乎都有很大的优势。从安全性来说，HTTP/3有其先进性也有其局限性。

安全优势

1.端到端加密

TCP协议旨在确保在传输过程中进行有效负载加密，但是对于特定传输的信息仍未加密，所以这会引发许多安全和隐私问题。预防攻击的对策不是在TCP堆栈上，而是在处理协议和网络的网络设备和中间盒上。此外，解析器可以克服负载均衡器和其他网络设备中的这些问题，但它们也还存在严重的性能问题，并且可能会限制网络发展速度和可靠性。

使用QUIC协议时，只有网段中的必填字段未加密，而其余信息默认情况下是加密的。通过查看TCP和QUIC的网络段，我们发现包括数据包标志（数据包NR和ACK NR），窗口和选项的字段在QUIC中已加密，但在TCP中未加密。QUIC中建议加密有助于防止普遍存在的监视攻击（在HTTP / 3的前身中很普遍）以及协议工件和元数据、应用程序数据的侵入式信息收集。

图1 Wireshark代码段显示QUIC协议的网段

2.TLS安全连接

为了在连接期间支持端到端加密，QUIC主要依赖于加密和传输层握手。由于QUIC直接与TLS 1.3 交互，因此它可用于所有原始连接的授权加密，并且没有禁用TLS。QUIC还负责确保建立安全连接，同时考虑到所有原始连接的机密性和完整性保护。与HTTP / 2 + TLS实现不同，QUIC在其传输上下文中处理TLS握手和警报机制，这反过来又帮助QUIC利用从握手交换的密钥来建立密码保护。

如果我们从整体上考虑该协议，则TLS和QUIC之间存在两个主要通信：

QUIC为TLS提供了稳定的流抽象，通过QUIC发送和接收消息。

TLS使用以下内容更新QUIC组件。

1.秘密的、经过身份验证的加密算法和密钥派生功能（KDF）

2.数据包保护密钥

3.协议状态更改（例如握手状态、服务器证书）

与使用TLS的“ application_data”记录的HTTP/2不同，QUIC使用STREAM帧，通过QUIC数据包形式展现。TLS握手以CRYPTO帧的形式形成，主要由连续流中的握手数据组成。QUIC旨在并行发送数据包，有时会将不同的消息捆绑成一个消息并加密，因为这些消息具有相同的加密级别。此功能为网络性能提供了极大的优势，同时确保在传输过程中应用正确的加密模式。

3.完全正向保密性

当在用户代理和服务器之间交换临时私钥时，可以实现协议中的完全前向保密性（PFS）。用户代理启动的每个会话都使用新的唯一会话密钥，并且它与先前的会话密钥没有任何关系。通过为每次传输使用单独的会话密钥，即使任何会话密钥被泄露，来自较早或将来会话的任何信息也不会受到破坏。从加密角度来看，没有密钥交换可以提供完美前向保密性。但是，完全正向保密性，一个新术语对PFS的实现提供了可能。

QUIC使用TLS 1.3，该协议支持椭圆曲线（EC）DHE密钥交换或有限字段上的预共享密钥（PSK）和Diffie-Hellman（DH）。0-RTT密钥交换提供了完全的正向保密性，因为加密规范仅接受通过0-RTT握手的前向安全连接。尽管TLS 1.2还支持前向保密性，但从技术上讲，当用户代理发送由只有服务器已知的对称密钥保护的机密资料副本时，正向保密性在会话恢复期间会丢失。该协议甚至为用户代理和服务器之间的初始消息提供了完全的正向保密。此外，由于QUIC协议不支持长期密钥，因此QUIC借助TLS 1.3可以使用其协议层为应用程序提供完全正向保密功能。

4.重放攻击防护

除了随机数，QUIC实现还用于存储密钥派生的客户端值。服务器会识别并拒绝具有相同密钥派生值和随机数的任何重复请求。考虑到用户代理和服务器之间的协议通信开销，这种设计被称为性能噩梦。从理论上讲，该解决方案看似适用，但是在实践中，该协议可能会变得很占内存并导致性能问题。当前的设计不是最好的，但是从协议层面来说，这会防止任何服务器多次接受同一密钥。同样，QUIC在初始步骤中不提供重放保护，而是在服务器初始回复后立即开始保护。QUIC是让初始交易能得到应用程序保护并减少协议所占内存。考虑到Web组件可能会使用从会话密钥派生的密钥，因此在此阶段可能会发生重放攻击。但是，可以在应用程序层面使用预防措施来减轻这种情况。

5.IP欺骗保护

6.防止SSL降级

TLS 1.3可以防止TLS降级攻击，因为该协议规定了所有握手通信的密钥哈希，并且要求握手接收方验证发送的密钥哈希。在握手过程中，任何检测到的对客户端功能的篡改尝试都将导致握手终止并出现错误。此外，检测还涉及用户代理与服务器之间的证书验证消息，包括有关特定连接的所有先前消息的PKCS RSA哈希签名。QUIC中的校验和实现将成功防止TLS降级攻击。

安全挑战

1.0-RTT恢复漏洞

HTTP / 3的最大优势之一是0-RTT恢复，它可以极大地提高连接速度并减少延迟。但是，仅当成功建立了先前的连接，并且当前交易使用在上一次连接期间建立了预共享机密时，这一优势才发挥作用。

0-RTT恢复功能存在一些安全方面的缺点。最常见的攻击媒介之一是重放攻击，当对手重新发送初始数据包时可能会造成这种攻击。在特定的情况下，这可能会迫使服务器认为该请求来自先前已知的客户端。恢复0-RTT的另一个安全缺点是完全前向保密的部分失效。如果对手破坏了令牌，那么他们就可以解密用户代理发送的0-RTT通信内容。

2.连接ID操纵攻击

连接ID操纵攻击要求将攻击者处在用户代理与服务器之间。他们可以在交换客户端和服务器问候消息的初始握手期间操纵连接ID。握手将照常进行，服务器假定已建立连接，但是用户代理将无法解密，因为连接ID需要加密密钥派生过程的输入步骤，并且用户代理和服务器将计算不同的加密键。用户代理最终将超时，并向服务器发送错误消息，告知连接已终止。由于客户端使用原始的加密密钥将错误消息加密到服务器，因此服务器将无法解密，并且将保持连接状态，直到空闲连接超时（通常在10分钟内）到期为止。

2.UDP放大攻击

3.流量耗尽型攻击

当对手有意启动多个连接流时，就会发生流耗尽攻击，这可能导致端点耗尽。攻击者可以通过反复提交大量请求来利用穷尽序列。尽管特定的传输参数可能会限制并发活动流的数量，但是在某些情况下，可能会故意将服务器配置设置为更高数值。由于服务器的协议配置增加了协议性能，因此受害服务器可能成为此类攻击的目标。

4.连接重置攻击

连接重置攻击主要是向受害者发送无状态重置，从而可能产生类似于TCP重置注入攻击的拒绝服务攻击。如果攻击者可以获得具有特定连接ID的连接生成的重置令牌，则可能存在潜在的攻击媒介。最后，攻击者可以使用生成的令牌重置具有相同连接ID的活动连接，从而使服务器等待连接，直到发生超时为止。如果大规模进行此攻击，则服务器必须大量消耗其资源，以等待连接完成。

5.QUIC版本降级攻击

QUIC数据包保护为通信中的所有数据包（版本协商数据包除外）提供身份验证和加密。版本协商数据包旨在协商用户代理和服务器之间QUIC的版本。该功能可能允许攻击者将版本降级到QUIC的不安全版本。该攻击目前暂时不会发生，因为只有QUIC的一个版本，但是将来需要注意。

6.缺少监视支持

尽管一些用户代理，服务器和信誉良好的网站支持HTTP3/QUIC，但是许多网络设备（例如反向/正向代理，负载均衡器，Web应用程序防火墙和安全事件监视工具）并不完全支持HTTP/3。与TCP不同，QUIC连接中不需要套接字，这使得检测主机和恶意连接变得更加困难。恶意攻击者可能能够通过QUIC中继恶意有效载荷并执行数据泄露攻击，并且保持隐身状态，因为大多数检测工具无法检测到QUIC流量。

QUIC的历史

2016年，互联网工程任务组（IETF）开始标准化Google的QUIC，并宣布IETF QUIC成为新HTTP/3版本的基础。但是，出于性能和安全方面的考虑，IETF QUIC与原始QUIC设计大相径庭。

TCP上的传统Web流量需要三向握手。QUIC使用UDP，由于往返次数减少和发送的数据包减少，因此延迟减少，从而加快了网络流量传输。UDP除了速度更快之外，还具有其他优点，包括连接迁移、改进延迟、拥塞控制和内置加密。根据Google的说法， “与TCP + TLS的1-3次往返相比， QUIC握手通常需要零往返来发送有效负载。” 第一个连接需要一个往返，而随后的连接则不需要任何往返。同样，由于QUIC用于多路复用操作，因此与TCP相比，它在数据包丢失方面做得更好，并且握手速度更快。

Google的QUIC版本现在是gQUIC。从gQUIC进化的HTTP/3，具备了重大的改进，并得到IETF工作组的贡献和增强。尽管从技术上讲HTTP/3是完整的应用程序协议，但QUIC指的是基础传输协议，它不限于服务Web流量。UDP是无连接的，不是很可靠。QUIC通过在UDP上添加类似于TCP的堆栈，来添加可靠的连接，并在其之上重新发送具有流控制功能的方式来克服这些限制，同时解决了TCP的行头阻塞问题。

HTTP/3使用UDP，类似于HTTP/2使用TCP的方式。每个连接都有几个并行流，这些并行流用于通过单个连接同时传输数据，而不会影响其他流。因此，与TCP不同，为特定的单个流承载数据的丢失数据包只会影响该特定的流。然后，每个流帧都可以在到达时立即分配给该流，因此可以在不丢失任何流的情况下继续在应用程序中重新组合。QUIC的这种连接建立策略是通过加密和传输握手的组合来实现的。

和HTTP/2的比较分析

QUIC旨在通过减轻HTTP/2的数据包丢失和延迟问题来提高性能。虽然HTTP/2对每个数据来源使用单个TCP连接，但这会导致行头阻塞问题。例如，一个请求的对象可能会停滞在另一个遭受丢失的对象之后，直到该对象恢复为止。QUIC通过将HTTP/2的流层向下推送到传输层来解决此问题，从而避免了应用程序层和传输层的问题。HTTP/3还支持多路复用，在与TLS直接集成的同时，提供独立于其他连接请求的请求。尽管HTTP/2和HTTP/3的工作方式相似，但以下是HTTP/2和HTTP/3的一些重要区别。

区别	HTTP/2	HTTP/3
传输	TCP	基于UDP的QUIC
流层	应用	传输
默认加密	无	有
独立流	无	有
报头压缩	HPACK	QPACK
握手	更快的0-RTT	TCP+TLS的1-3RTT
连接消除	无	有
拥塞控制损失恢复	由TCP执行	由QUIC执行

从网络堆栈的角度来看，HTTP/2广泛使用了符合HTTP标准的TLS 1.2+，底层的TCP充当了传输协议。但是，在HTTP/3中，默认情况下，除了QUIC以外，还使用TLS 1.3，而UDP是传输协议。下图说明了QUIC在网络协议堆栈中的位置。相比之下，以前的版本使用TLS 1.2，并使用TCP的拥塞控制丢失恢复功能，而HTTP/2处理多流功能。

图2： QUIC在网络协议堆栈中的位置

连接ID的优势

从协议的角度来看，连接ID提供了其他好处。服务器和用户代理可以使用连接ID识别原始连接和重传连接，并避免TCP中普遍存在的重传歧义问题。

结论

QUIC已获得多数浏览器的支持。YouTube和Facebook等重要网站已启用该功能，可以更快地加载页面。在撰写本文时，目前只有4％的顶级网站支持QUIC。微软已经宣布，他们将在内核中交付带有通用QUIC库MsQuic的Windows，以支持各种收件箱功能。

QUIC和HTTP/3旨在满足当今互联网网络性能、可靠性和安全性的目标。强制性支持TLS 1.3的安全性得到了显着改善，从而解决了HTTP/2和早期版本的HTTP的弱点。在HTTP/3传输过程中使用端到端加密有助于抵御攻击者和数据聚合者的一些隐私问题。尽管存在一些弱点，但从性能和安全性角度来看，HTTP/3仍将继续发展，不管怎么说都是对HTTP/2的重大改进。

参考链接：

HTTP/3增强安全性的6种方式

交易担保 FreeBuf+ FreeBuf+小程序：把安全装进口袋 Mini Program

精彩推荐