JDK 27：后量子 TLS 混合密钥交换，Java 安全栈开始进入 PQC 迁移

分享日期：2026-06-12
主题：Java / JDK 27 / TLS 1.3 / 后量子密码 / ML-KEM

1. 为什么今天值得关注

OpenJDK 的 JDK 27 项目页目前列出的目标特性是 JEP 527：Post-Quantum Hybrid Key Exchange for TLS 1.3。这个 JEP 的状态已经标记为 Completed，目标版本是 JDK 27，组件落在 security-libs / javax.net.ssl。

这件事对 Java 团队的意义不是“又多了一个加密算法”，而是 JDK 的 TLS 默认能力开始接入后量子密码迁移路线。只要应用实际使用的是 JDK 自带的 JSSE，也就是 javax.net.ssl 这套 TLS 实现，并且没有手动锁死 named groups，未来升级到 JDK 27 后就可能在 TLS 1.3 握手中默认优先尝试后量子混合密钥交换。

后量子密码现在看起来像安全团队的话题，但它会逐渐影响后端团队的日常运行：

• Java 服务到数据库、消息队列、网关、对象存储、第三方 API 的 TLS 连接都会进入排查范围。
• 证书、签名算法、TLS key exchange、负载均衡器和代理链路需要分层理解，不能混成一个“换证书”的问题。
• 现在做清单和灰度，比未来被合规或浏览器生态倒逼迁移要从容得多。

一句话：JDK 27 把 Java 的后量子支持从“安全 API 能用”推进到“TLS 网络通信开始默认接入”。

2. 先把三个概念说清楚

2.1 KEM：密钥封装机制

KEM 是 Key Encapsulation Mechanism，用来让通信双方在公开信道上建立共享密钥。Java 21 通过 JEP 452 引入了标准 javax.crypto.KEM API，为后续接入后量子密钥交换打了底座。

业务开发不一定要直接写 KEM 代码，但需要知道它和 TLS 的关系：TLS 握手最终要协商出双方共享的秘密材料，再派生出对称加密密钥。KEM 是实现这件事的一种现代密码学构件。

2.2 ML-KEM：NIST 标准化的后量子 KEM

ML-KEM 是 Module-Lattice-Based Key-Encapsulation Mechanism。NIST 在 FIPS 203 中标准化了 ML-KEM，并定义了 ML-KEM-512、ML-KEM-768、ML-KEM-1024 三组参数。

Java 24 通过 JEP 496 在 JDK 里提供了 ML-KEM 实现，支持 KeyPairGenerator、KEM 和 KeyFactory。这一步解决的是“JDK 里有没有 ML-KEM 算法实现”的问题。

2.3 混合密钥交换：ECDHE + ML-KEM

JEP 527 要做的是 TLS 1.3 的混合密钥交换。所谓混合，不是简单替换传统算法，而是把传统 ECDHE 和后量子 ML-KEM 组合起来。

这样做的现实原因很直接：

• 传统 ECDHE 经受过多年工程验证，但未来可能被大规模量子计算威胁。
• ML-KEM 面向后量子威胁，但工程生态和互操作验证还在成熟。
• 混合方案要求两边都被攻破才失去密钥交换安全性，因此更适合迁移阶段。

这也是为什么 JDK 27 优先做 hybrid key exchange，而不是直接把 TLS 全面切到纯 ML-KEM。

3. JEP 527 实际改了什么

JEP 527 会增强 JDK 的 TLS 1.3 实现，加入三组后量子混合 named groups：

• X25519MLKEM768：X25519 ECDHE + ML-KEM-768。
• SecP256r1MLKEM768：secp256r1 ECDHE + ML-KEM-768。
• SecP384r1MLKEM1024：secp384r1 ECDHE + ML-KEM-1024。

默认策略更值得关注：JDK 会把 X25519MLKEM768 放到 TLS 1.3 客户端默认 named groups 列表的最前面。也就是说，客户端会优先尝试这个混合组，同时仍然保留 x25519、secp256r1、secp384r1 等传统组作为互操作基础。

如果对端不支持混合组，正常 TLS 协商应当退回传统组；如果应用、框架或运行参数手动指定了 named groups，则默认列表可能被覆盖，是否能用上混合组取决于你的配置。

4. 哪些 Java 应用会受影响

优先关注这几类系统：

• 使用 JDK HttpClient、HttpsURLConnection 或基于 JSSE 的 HTTP 客户端。
• 使用 JDK TLS provider 的 Spring Boot 服务、RPC 客户端、数据库驱动、消息队列客户端。
• 自建 TLS socket、双向 TLS、内部网关到服务之间的 Java 客户端。
• 对外访问云服务、SaaS、支付、身份认证、对象存储等 HTTPS API 的后端服务。

同时要排除几个误区：

• 如果服务的 TLS 终止在 Nginx、Envoy、云负载均衡或 API Gateway，Java 应用本身可能只看到内网明文或另一段 TLS。
• 如果底层使用 OpenSSL、BoringSSL、Conscrypt、Netty native transport 或平台 TLS provider，就不一定走 JDK 的 javax.net.ssl。
• 证书签名算法和 TLS 密钥交换不是一回事。JEP 527 处理的是 TLS 1.3 key exchange，不是把证书签名自动改成后量子签名。

所以第一步不是改代码，而是画清楚每条链路到底是谁在做 TLS。

5. 生产风险不在“能不能编译”，而在链路互操作

JEP 527 的设计目标是让使用 javax.net.ssl 的应用在多数情况下不改代码就受益。但生产迁移仍然要验证三类问题。

5.1 握手体积和延迟

混合 key share 会让 TLS ClientHello 和握手数据变大。大多数现代网络链路能处理，但老旧代理、严格 WAF、异常 MTU、特殊网关设备可能暴露问题。

需要观察：

• TLS 握手耗时。
• 首次连接失败率。
• 连接重试次数。
• 网关、代理、WAF 的丢弃或截断日志。

5.2 named groups 被手动锁死

很多系统为了合规或历史兼容，会配置：

-Djdk.tls.namedGroups=x25519,secp256r1,secp384r1

这类配置会覆盖默认行为。如果未来希望启用混合密钥交换，就需要把 X25519MLKEM768 加回列表，并保留传统组作为回退：

-Djdk.tls.namedGroups=X25519MLKEM768,x25519,secp256r1,secp384r1

原则是：不要只配置一个新组；迁移期一定要保留成熟传统组，保证对端不支持时能协商成功。

5.3 规范仍在演进

JEP 527 明确提到，相关 IETF TLS 混合密钥交换规范在交付时仍处于 draft 阶段。如果后续 RFC 阶段发生实质变化，JDK 实现也可能调整。

这意味着企业内部不应把 JDK 27 的这一能力直接写成“合规已经完成”。更稳妥的表述是：Java TLS 栈已经具备后量子迁移的早期工程基础，可以开始做链路验证、资产清点和灰度策略。

6. Java 侧如何显式配置

大多数应用不需要显式写代码。如果确实要按连接定制 named groups，可以通过 SSLParameters：

        SSLSocket tlsSocket = (SSLSocket) SSLContext.getDefault().getSocketFactory().createSocket();
        SSLParameters parameters = tlsSocket.getSSLParameters();
        parameters.setNamedGroups(new String[] { "X25519MLKEM768", "x25519", "secp256r1" });
        tlsSocket.setSSLParameters(parameters);

更常见的是通过 JVM 参数统一控制：

java \ -Djdk.tls.namedGroups=X25519MLKEM768,x25519,secp256r1,secp384r1 \ -jar app.jar

灰度建议是先在测试环境打开 javax.net.debug 查看握手协商，再在少量非核心流量中验证：

java -Djavax.net.debug=ssl:handshake -jar app.jar

注意：调试日志可能包含敏感连接信息，不要在生产全量长期开启。

7. 团队落地清单

1. 盘点所有 Java 服务的 JDK 版本、TLS provider、HTTP/RPC/DB/MQ 客户端和网关链路。
2. 标记哪些连接实际使用 javax.net.ssl，哪些连接被网关、sidecar 或 native TLS 库接管。
3. 搜索 jdk.tls.namedGroups、SSLParameters#setNamedGroups、容器启动参数和基础镜像默认参数。
4. 为 JDK 27 EA 或后续正式版本准备一组 TLS 互操作测试：内网服务、数据库、消息队列、第三方 API、老旧代理。
5. 建立回滚开关：保留传统 named groups，并能快速移除混合组。
6. 和安全团队对齐术语：这是 TLS key exchange 的后量子迁移，不是证书体系、签名体系和密钥管理体系的一次性全部替换。

8. 强化理解

JDK 27 的后量子 TLS 不是一个“马上要改业务代码”的需求，而是一个“现在要开始做基础设施清点”的信号。

对多数 Java 后端团队，最务实的动作不是马上升级生产 JDK，而是把 TLS 链路从黑盒变成清单：

• 谁发起 TLS？
• 谁终止 TLS？
• 用的是 JDK JSSE 还是别的 provider？
• 有没有手动锁死算法组？
• 出问题时能不能按 named group 快速回滚？

把这些问题回答清楚，后量子迁移就从抽象安全概念变成了可执行的工程任务。

9. 分享金句

后量子 TLS 的重点不是让 Java 应用“立刻变成量子安全”，而是让团队提前掌握 TLS 链路、算法配置和回滚开关；真正成熟的安全迁移，第一步永远是把黑盒变成清单。

短文案

JDK 27 的 JEP 527 已完成，Java TLS 1.3 将开始接入后量子混合密钥交换。重点不是马上改业务代码，而是确认服务到底是不是走 javax.net.ssl、有没有锁死 jdk.tls.namedGroups、网关和代理能不能处理新的握手行为。后量子迁移离业务后端并不远，它首先会表现为一次 TLS 链路治理。

参考资料

• OpenJDK JDK 27 项目页
• JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
• JEP 452: Key Encapsulation Mechanism API
• JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard