为了在连接期间支持端到端加密，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.3可以使用其协议层为应用程序提供完全正向保密功能。

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/javastacks/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处理多流功能。

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

连接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技术栈，在后台发送：面试，可以在线阅读。