HTTP/2 都还没上用，HTTP/3 又是什么鬼？

点击关注微信官方账号，Java干货及时送达

作者：IT影子
链接：https://www.jianshu.com/p/b0b3c6df1a16

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显示QUIC网络分析器工具协议Wireshark呈现方式QUIC网段，互联网协议（IP）层保存源IP地址和目标IP地址信息。UDP保留源端口和目标端口，QUIC包含公共标志，数据包编号，连接ID加密的有效负载。

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它旨在并行发送数据包，有时将不同的信息绑定到一个消息并加密，因为它们具有相同的加密级别。该功能为网络性能提供了巨大的优势，并确保在传输过程中应用正确的加密模式。最新的面试问题已经完成，点击Java面试库小程序在线刷题。

3.完全正向保密

在用户代理和服务器之间交换临时私钥时，协议中的完全前向保密性可以实现（PFS）。用户代理启动的每个会话都使用新的唯一会话密钥，与之前的会话密钥无关。

通过使用单独的会话密钥进行每次传输，即使任何会话密钥泄露，来自早期或未来的会话信息也不会被破坏。从加密的角度来看，没有密钥交换可以提供完美的前向保密。然而，完全积极的保密，一个新术语是正确的PFS实现提供了可能性。

QUIC使用TLS 1.3.该协议支持椭圆曲线（EC）DHE密钥交换或有限字段上的预共享密钥（PSK）和Diffie-Hellman（DH）。0-RTT由于加密规范只接受0，密钥交换提供了完全的正向保密性-RTT握手的前向安全连接。

尽管TLS 1.2也支持前向保密，但从技术上讲，当用户代理发送只有服务器已知的对称密钥保护的机密副本时，正向保密将在会话恢复期间丢失。该协议甚至为用户代理和服务器之间的初始信息提供了完全的积极保密。此外，由于QUIC因此，该协议不支持长期密钥QUIC借助TLS 1.其协议层可用于为应用程序提供完全正向的保密功能。

4.重放攻击防护

除随机数外，QUIC实现还用于存储密钥衍生物的客户端值。服务器将识别并拒绝任何有相同密钥衍生值和随机数的重复请求。考虑到用户代理和服务器之间的协议通信费用，这种设计被称为性能噩梦。

从理论上讲，该解决方案似乎适用，但在实践中，该协议可能会占用内存并导致性能问题。目前的设计不是最好的，但从协议的角度来看，这将防止任何服务器多次接受相同的钥匙。

同样，QUIC在初始步骤中不提供重放保护，而是在服务器初始回复后立即开始保护。QUIC应用程序保护初始交易，减少协议内存。Web组件可能使用从会话密钥衍生的密钥，因此在这个阶段可能会发生重放攻击。然而，这种情况可以通过在应用程序层面使用预防措施来减少。

5.IP欺骗保护

QUIC握手期间支持地址验证，需要签地址证明，以消除任何地址IP欺骗攻击。IP地址欺址的主要问题是QUIC通过广泛使用源地址令牌，源地址令牌是服务器身份验证的加密块，包括用户代理IP服务器的地址和时间戳。

除连接更改、IP地址没有变化。由于源地址令牌被用作承载令牌，它们可以重复使用，并且可以绕过任何服务器设置IP地址限制。因为服务器只响应令牌中的响应IP地址，所以即使被盗，cookie或者令牌不会成功IP欺骗。

6.防止SSL降级

TLS 1.3可以防止TLS降级攻击，因为协议规定了所有握手通信的密钥哈希，并要求握手接收器验证发送的密钥哈希。在握手过程中，任何篡改客户端功能的测试都会导致握手终止和错误。

此外，检测还涉及用户代理与服务器之间的证书验证信息，包括所有具体连接的先前信息PKCS RSA哈希签名。QUIC成功防止中学校验和实现TLS降级攻击。

安全挑战

1.0-RTT恢复漏洞

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

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

点击关注公众号，Java干货及时送达

2.连接ID操纵攻击

连接ID操纵攻击要求攻击者在用户代理和服务器之间。在交换客户端和服务器问候信息的初始握手期间，他们可以操纵连接ID。握手将像往常一样进行，服务器假设已经建立了连接，但由于连接，用户代理将无法解密ID输入步骤需要加密密钥衍生过程，用户代理和服务器将计算不同的加密键。

用户代理最终将加班并向服务器发送错误信息，告知连接已终止。由于客户端使用原始加密钥将错误信息加密到服务器，服务器将无法解密并保持连接状态，直到空闲连接加班（通常在10分钟内）到期。

同样的攻击可能会导致服务器拒绝服务攻击，并保留多个连接，直到连接状态过期。保持有效连接的另一种攻击方法是更改其他参数，如源地址令牌，以防止客户端建立任何连接。

最新的面试问题已经整理好了，点击Java面试库小程序在线刷题。

2.UDP放大攻击

为了成功地放大攻击，攻击者必须欺骗受害者IP地址，并将UDP请求发送到服务器。如果服务器返回更重要UDP如果响应，攻击者可以大规模使用该服务器并创建它DDOS攻击情形。

具体来说，在QUIC当对手从目标接受地址验证令牌并释放最初用于生成令牌时IP会发生地址UDP放大攻击。攻击者可以使用相同的IP地址将0-RTT连接并发送回服务器IP地址可能已经改为不同的端点。

通过执行此设置，攻击者可以潜在地指示服务器向受害者服务器发送大量流量。为了防止这种攻击，HTTP / 3具有速度限制功能和短期验证令，可作为DDOS攻击的补偿控制，同时部分缓解攻击情形。

推荐一个 Spring Boot 基础教程及实战示例：https://github.com/javatacks/javastack

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

连接ID的优势

TCP连接即利用数据源和目标网络实体（主要是地址和端口）来标识特定连接。但是，QUIC连接使用连接ID，它是64位随机生成的客户端标识符。这项更改对于当前的Web技术非常有利，主要是因为要求它们支持用户的移动性。如果用户从Wi-Fi网络移动到蜂窝网络，则HTTP/2 TCP协议将需要基于当前地址建立新的连接。但是，由于HTTP/3 QUIC协议使用随机连接ID，因此当从蜂窝网络转移到Wi-Fi连接时，HTTP/3上的客户端更改IP地址将继续使用现有的连接ID而不会中断。

从协议的角度来看，连接ID提供了其他好处。服务器和用户代理可以使用连接ID识别原始连接和重传连接，并避免TCP中普遍存在的重传歧义问题。另外，HTTP 系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。

结论

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

QUIC和HTTP/3旨在满足当今互联网网络性能、可靠性和安全性的目标。强制性支持TLS 1.3的安全性得到了显着改善，从而解决了HTTP/2和早期版本的HTTP的弱点。

在HTTP/3传输过程中使用端到端加密有助于抵御攻击者和数据聚合者的一些隐私问题。尽管存在一些弱点，但从性能和安全性角度来看，HTTP/3仍将继续发展，不管怎么说都是对HTTP/2的重大改进。

关注Java技术栈看更多干货

获取 Spring Boot 实战笔记！