Java 25 active d'office une protection de ses connexions contre les ordinateurs quantiques

Le 20 octobre, Oracle a publié son dernier correctif trimestriel de l'année : 1 209 failles corrigées dans 33 familles de produits. Une ligne des notes de version de Java 25.0.5 change pourtant davantage que bien des correctifs : les applications Java proposent désormais d'elles-mêmes un échange de clés post-quantique à chaque connexion TLS 1.3, le protocole qui chiffre le trafic web.

D'après ces notes de version, la mise à jour ajoute trois combinaisons dites hybrides. L'une d'elles, X25519MLKEM768, est activée par défaut et proposée en premier. Aucune modification du code n'est nécessaire, pourvu que l'autre bout de la connexion la prenne aussi en charge. Le suivi de bogues d'OpenJDK confirme ce portage vers la branche 25.0.5 (JDK-8387671). Jusqu'ici, la fonction n'existait que dans Java 27, sorti le 15 septembre, alors que Java 25 est la version à support long, celle que la plupart des entreprises utilisent.

Pourquoi combiner deux algorithmes ?

Le principe hybride associe l'échange de clés classique X25519 à ML-KEM-768, l'algorithme post-quantique normalisé par le NIST, l'institut américain des normes. Si l'un des deux venait à céder, l'autre protégerait encore la clé de session. La demande de modification (CSR) qui encadre ce changement dans le JDK explique pourquoi agir maintenant : un adversaire peut enregistrer aujourd'hui du trafic chiffré pour le déchiffrer plus tard, une fois qu'un ordinateur quantique suffisant existera.

Les deux autres combinaisons, SecP256r1MLKEM768 et SecP384r1MLKEM1024, restent désactivées tant qu'on ne les demande pas. Le texte justifie ce choix : n'activer que X25519MLKEM768 reprend l'approche de la plupart des navigateurs et bibliothèques qui gèrent déjà ces schémas. Il juge le risque de compatibilité « minimal ».

Pourquoi certaines applications ne verront aucun changement

Le changement ne vaut que pour TLS 1.3, et seulement si le serveur ou le client d'en face connaît ce schéma. Surtout, une application qui fixe sa propre liste de schémas, avec la propriété système jdk.tls.namedGroups ou la méthode SSLParameters.setNamedGroups(), garde sa liste : la nouveauté ne s'y ajoute pas. Ces réglages, souvent posés il y a des années pour durcir une configuration, risquent de priver certains services de la protection sans que personne ne s'en aperçoive.

Java 21 et Java 17 suivront. Le suivi de bogues d'OpenJDK mentionne des portages déjà terminés pour les versions 21.0.14 et 17.0.22 d'Oracle JDK, qu'un contributeur du projet Apache Camel Quarkus attend pour 2027.

Que faire ?

La mise à jour d'octobre apporte aussi des correctifs de sécurité : selon un décompte de Tenable, 55 concernent Java SE, dont 49 exploitables à distance sans authentification. Il faut donc l'installer de toute façon.

• Passez vos environnements Java 25 en 25.0.5, en vérifiant que votre distribution (Oracle ou autre version d'OpenJDK) intègre bien le changement.
• Cherchez dans vos scripts de démarrage et votre code les réglages jdk.tls.namedGroups et setNamedGroups, et ajoutez-y X25519MLKEM768 si vous voulez en profiter.
• Testez les connexions qui traversent des proxys, des répartiteurs de charge ou des équipements d'inspection du trafic avant de généraliser.
• Mettez à jour votre inventaire cryptographique : une connexion qui négocie le schéma hybride le fait savoir dans la poignée de main TLS.

Les développeurs .NET ont eux aussi commencé à tester le chiffrement post-quantique hybride, et le Royaume-Uni a publié les réglages TLS à activer sur les serveurs. Il restera à voir combien d'applications profiteront vraiment de ce changement par défaut : la réponse dépend d'abord des configurations figées.