Java最全面试题

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欺骗保护

QUIC在握手期间支持地址验证，并且需要签名的地址证明，从而消除了任何IP欺骗攻击。IP地址欺骗问题主要在QUIC中通过广泛利用“源地址令牌”来解决，“源地址令牌”是服务器的经过身份验证的加密块，其中包含用户代理的IP地址和服务器的时间戳。用户代理可以重复使用服务器生成的源地址令牌，除非连接更改、IP地址不在变化。由于源地址令牌用作承载令牌，因此它们可以反复使用，并且可以绕过服务器设置的任何IP地址限制。由于服务器仅响应令牌中的IP地址，因此即使是被盗的cookie或令牌也不会成功进行IP欺骗。

6、防止SSL降级

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

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!