Java 25 now turns on quantum-resistant protection for its connections by default
Java 25.0.5, released October 20, puts a quantum-resistant hybrid key exchange first among its TLS choices. Here is what changes, what can keep it from working, and what to check.
Translated from French by AI. The original French article is the reference version.
On October 20, Oracle released its last quarterly patch of the year: 1,209 vulnerabilities fixed across 33 product families. Yet one line in the release notes for Java 25.0.5 matters more than many patches: Java applications now offer a post-quantum key exchange on their own for every TLS 1.3 connection, the protocol that encrypts web traffic.
According to those release notes, the update adds three so-called hybrid combinations. One of them, X25519MLKEM768, is enabled by default and offered first. No code change is needed, as long as the other end of the connection supports it too. The OpenJDK bug tracker confirms the backport to the 25.0.5 branch (JDK-8387671). Until now, the feature existed only in Java 27, released on September 15, while Java 25 is the long-term support release, the one most companies use.
Why combine two algorithms?
The hybrid approach pairs the classic X25519 key exchange with ML-KEM-768, the post-quantum algorithm standardized by NIST, the US standards institute. If one of the two were ever broken, the other would still protect the session key. The change request (CSR) governing this change in the JDK explains why to act now: an adversary can record encrypted traffic today and decrypt it later, once a sufficiently powerful quantum computer exists.
The other two combinations, SecP256r1MLKEM768 and SecP384r1MLKEM1024, stay disabled unless you request them. The text justifies this choice: enabling only X25519MLKEM768 follows the approach of most browsers and libraries that already handle these schemes. It rates the compatibility risk as “minimal.”
Why some applications will see no change
The change applies only to TLS 1.3, and only if the server or client on the other side knows this scheme. Above all, an application that sets its own list of schemes, using the jdk.tls.namedGroups system property or the SSLParameters.setNamedGroups() method, keeps its list: the new option is not added to it. These settings, often put in place years ago to harden a configuration, may leave some services without the protection and no one will notice.
Java 21 and Java 17 will follow. The OpenJDK bug tracker mentions backports already completed for Oracle JDK versions 21.0.14 and 17.0.22, which a contributor to the Apache Camel Quarkus project expects in 2027.
What to do
The October update also brings security fixes: according to a Tenable count, 55 concern Java SE, 49 of them remotely exploitable without authentication. So you need to install it anyway.
- Move your Java 25 environments to 25.0.5, checking that your distribution (Oracle or another OpenJDK build) actually includes the change.
- Search your startup scripts and code for the
jdk.tls.namedGroupsandsetNamedGroupssettings, and addX25519MLKEM768to them if you want the benefit. - Test connections that pass through proxies, load balancers or traffic inspection devices before rolling out widely.
- Update your cryptographic inventory: a connection that negotiates the hybrid scheme signals it in the TLS handshake.
.NET developers have also started testing hybrid post-quantum encryption, and the United Kingdom has published the TLS settings to enable on servers. It remains to be seen how many applications will really benefit from this default change: the answer depends first on frozen configurations.
Method: AI-assisted monitoring, verified sources, article reviewed and approved by Frédéric LENQUETTE. Our editorial policy.
Share this article
