OpenSSL 4.1 apporte DTLS 1.3 après deux semaines de retard

OpenSSL 4.1.0 est disponible. Le projet a étiqueté la version le 23 octobre 2026, et sa nouveauté phare est DTLS 1.3, la version la plus récente du protocole de chiffrement pour le trafic envoyé sous forme de datagrammes séparés. De nombreuses applications tirent leur chiffrement d'OpenSSL. Le support dans OpenSSL détermine donc à partir de quand ces applications peuvent tout simplement activer DTLS 1.3.

La version publiée sur GitHub la présente comme « une version de fonctionnalités qui ajoute de nouvelles fonctions importantes ». Phoronix a signalé la version stable le matin même.

Les nouveautés d'OpenSSL 4.1

DTLS est la version de TLS conçue pour UDP, où les paquets peuvent arriver en retard, dans le désordre ou pas du tout. TLS est le protocole derrière le cadenas du navigateur. DTLS 1.3 suit la RFC 9147, la norme publiée en avril 2022. Le support d'OpenSSL arrive donc plus de quatre ans après la spécification.

Les notes de version listent ces changements :

Changement	Ce qu'il fait
DTLS 1.3 (RFC 9147)	Le TLS pour datagrammes le plus récent, avec une nouvelle page de guide, ossl-guide-dtlsv13(7)
DTLS dans l'API listener	Un seul socket serveur peut accepter de nombreux clients DTLS
GREASE (RFC 8701)	Envoie des valeurs factices aléatoires pour repérer les serveurs qui plantent face à des valeurs inconnues
IKEv2 KDF	Dérivation de clés utilisée par l'échange de clés du VPN IKEv2
Elbrus2000 (e2k)	Support initial de cette architecture de processeur
Nouvelles cibles MSVC 2013	Cibles de compilation VC-WIN32-MSVC2013 et VC-WIN64A-MSVC2013

GREASE mérite une ligne d'explication de plus. Les clients envoient des valeurs inventées dans des champs où de futures versions pourraient en ajouter de vraies. Un serveur qui plante à cause d'elles est repéré dès maintenant, avant qu'une vraie extension ne sorte.

Des calculs post-quantiques plus rapides

Une grande partie du travail sur la vitesse vise la cryptographie post-quantique. ML-DSA et ML-KEM sont de nouveaux algorithmes de signature et d'échange de clés conçus pour résister aux futurs ordinateurs quantiques. Un code plus rapide pour eux réduit le coût de la transition.

Selon les notes de version, la 4.1 ajoute du code AVX-512 pour le hachage SHAKE qu'utilise ML-DSA sur les puces x86_64. Elle accélère les calculs de ML-DSA et ML-KEM sur ppc64le, l'architecture POWER d'IBM. Les instructions AVX-512 et VAES accélèrent aussi le déchiffrement AES-CBC sur x86_64.

Ce qui a été supprimé

La version abandonne deux anciennes plateformes Windows, note Phoronix : Windows sur Itanium (VC-WIN64I) et Windows CE (VC-CE). Les options de compilation no-ecdsa et no-ecdh disparaissent aussi ; leur remplaçant est no-ec. Le script d'aide tsget nécessite désormais le module Perl Net::Curl::Easy au lieu de WWW::Curl::Easy.

Pourquoi la version finale a pris du retard

La route vers 4.1.0 a été cahoteuse. Selon Linux Compatible, 4.1.0-beta2 est sortie le 9 octobre à la place de la version finale prévue. Deux problèmes de sécurité DTLS, #33172 et #33173, sont apparus pendant la bêta et ont bloqué le tag. Le site indique qu'ils semblent avoir été corrigés avant la sortie du 23 octobre.

La version est tout de même livrée avec quatre bugs DTLS connus. Le plus important, #32878, concerne les mises à jour de clés. Après un KeyUpdate DTLS 1.3, d'autres enregistrements en attente peuvent sortir du tampon de renvoi. Un ticket de session perdu risque alors de ne jamais être renvoyé. Un correctif est prévu pour une version ultérieure. Linux Compatible énumère aussi des limites : pas de support du Connection ID de DTLS 1.3, et DTLS 1.3 sur SCTP se rabat sur des versions plus anciennes.

Dates de support

OpenSSL 4.1 n'est pas une version à support long terme. La page de téléchargement du projet indique sa fin de vie en novembre 2027. OpenSSL 4.0, dont le dernier correctif est la 4.0.3 du 29 septembre, est maintenu jusqu'au 14 mai 2027. OpenSSL 3.5 reste la version à long terme, maintenue jusqu'au 8 avril 2030.

La politique de versions du projet exclut toute rupture d'API ou d'ABI dans une version mineure. Selon Linux Compatible, la 4.1 reste compatible avec la branche 4.0. La plupart des applications compilées avec la 4.0 ne devraient donc pas avoir besoin d'être recompilées.

Ce que cela signifie pour les développeurs

Si vous exploitez des services UDP qui utilisent DTLS, la 4.1 est le premier OpenSSL avec la 1.3. Essayez-la en préproduction, pas en production. Les quatre bugs ouverts se trouvent tous dans le nouveau code DTLS, et #32878 peut perdre des tickets de session après une mise à jour de clé. Faites vos propres tests de mise à jour de clé et de perte de paquets avant de vous y fier.

Les serveurs qui acceptent de nombreux clients DTLS sur un seul socket devraient examiner l'API listener. Selon Linux Compatible, SSL_new_listener() gère désormais DTLS 1.3 et remplace DTLSv1_listen(), qui ne couvrait que DTLS 1.0 et 1.2.

La plupart des utilisateurs de TLS sur TCP peuvent mettre à jour selon leur calendrier habituel. Les accélérations post-quantiques sont rentables sur les serveurs x86_64 avec AVX-512 et sur les systèmes POWER.

Planifiez votre fenêtre de support. Si votre produit a besoin d'une bibliothèque maintenue au-delà de 2027, restez sur la version à long terme 3.5 et traitez la 4.1 comme une branche de courte durée. Les builds Windows pour Itanium ou CE doivent rester sur la 4.0 ou une version antérieure.