量子计算的进步威胁到了 TLS 长期使用的加密机制。Google 认为，如果研究以当前的速度继续发展，TLS 中使用的非对称加密的安全性最早可能会在 2029 年被量子计算机破解。
为了降低此风险， Google Cloud 负载平衡器支持后量子密钥交换功能，旨在抵御量子计算机的理论能力。这些算法由美国国家标准与技术研究院 (NIST) 开发和审查，其在 TLS 中的使用符合 IETF 正在制定的标准。
如需了解详情，请参阅 Google Cloud中的后量子加密。
量子计算如何威胁 TLS 安全性
在密码学方面具有相关性的量子计算机将能够针对 TLS 安全性的两个关键组件（密钥交换和身份验证）发起攻击。
针对密钥交换的攻击
在密码学方面具有相关性的量子计算机将能够破解 TLS 握手期间使用的密钥交换算法，从而泄露用于加密 TLS 会话的对称密钥，并以明文形式暴露应用层流量。即使对于使用完全正向加密密钥交换方法（例如 ECDHE）的 TLS 连接，也是如此。如果攻击者今天记录了整个 TLS 会话，那么即使在几年后量子计算能力可用时，他们也可以解密该会话，这就是所谓的“先收集，后解密”攻击。
针对身份验证的攻击
在密码学方面有意义的量子计算机将能够破解 TLS 证书或证书授权机构中使用的密钥，从而使攻击者能够虚假地声明客户端或服务器身份。如果与中间人攻击结合使用，此漏洞可能会让攻击者查看和操纵 TLS 加密会话的内容。与针对密钥交换的攻击不同，针对身份验证的攻击无法针对记录的流量进行追溯性攻击。不过，针对身份验证的攻击会严重威胁 Web 身份验证的完整性。
对称密码不会受到威胁
在握手和身份验证完成后用于加密 TLS 会话的对称加密密码（例如 AES-128、AES-256 和 ChaCha20）不会受到量子计算的威胁。
后量子密钥交换
为了降低“先收集后解密”攻击的风险，我们建议您为客户端与负载平衡器之间的连接启用后量子密钥交换。
后量子密钥交换仅支持前端 TLS 连接，即客户端与负载均衡器之间的连接。
可以为以下负载平衡器启用后量子密钥交换：
- 全球外部应用负载均衡器
- 传统应用负载均衡器
- 区域外部应用负载均衡器
- 跨区域内部应用负载均衡器
- 区域级内部应用负载均衡器
- 全球外部代理网络负载均衡器
- 传统代理网络负载均衡器
X25519MLKEM768 是 Google Cloud 负载平衡器中支持的特定形式的后量子密钥交换。这是一种混合密钥交换方法，这意味着它受到经典加密机制和后量子加密机制的双重保护。
启用后量子密钥交换后，负载均衡器会在连接到通告支持 TLS 1.3 和 X25519MLKEM768 的客户端时使用该功能。连接到不支持 TLS 1.3 或 X25519MLKEM768 的客户端时不受影响。
启用后量子密钥交换后，当连接的客户端声明支持 TLS 1.3 和 X25519MLKEM768 密钥交换机制时，负载均衡器会使用该机制。来自不支持 TLS 1.3 或 X25519MLKEM768 的客户端的连接不受影响。
启用后量子密钥交换
您可以通过以下方式在负载均衡器上启用后量子密钥交换：在 SSL 政策中使用 post-quantum-key-exchange 设置，方法是将新的 SSL 政策附加到现有的 TargetHttpsProxy 或 TargetSslProxy，或者修改已附加的 SSL 政策。
如需详细了解如何创建具有后量子密钥交换设置的 SSL 政策，请参阅创建 SSL 政策。
我们建议您立即启用后量子密钥交换，因为它可以立即防范“现在收集，日后解密”攻击。正确实现的客户端预计不会遇到问题。不过，如果您的客户端应用不兼容，您可以将 post-quantum-key-exchange 设置为 DEFERRED，这样您就可以延迟到 2027 年 10 月再启用后量子密钥交换，从而有时间让您的应用变得兼容。
后量子密钥交换推出
由于后量子密钥交换提供的安全保护非常重要， Google Cloud 将于 2026 年 10 月开始默认启用此功能。这会影响未附加 SSL 政策或使用未设置后量子密钥交换的 SSL 政策的负载平衡器。如果需要，您可以使用 DEFERRED 设置将启用后量子密钥交换的时间推迟到 2027 年 10 月。
以下时间轴显示了计划为负载平衡器推出后量子密钥交换支持的时间。
| 时间轴 | 后量子密钥交换状态 |
|---|---|
| 现在 | 默认处于停用状态，只有在设置为 ENABLED 时才会启用 |
| 2026 年 10 月之后 | 默认处于启用状态，设置为 DEFERRED 时处于停用状态 |
| 2027 年 10 月之后 | 始终启用 |