OpenSSL 4.1 est disponible : DTLS 1.3, GREASE et les nouveautés expliquées

OpenSSL 4.1.0 est disponible en version stable depuis le 23 octobre 2026. Cette nouvelle édition de la bibliothèque cryptographique apporte DTLS 1.3, la prise en charge de GREASE et plusieurs optimisations pour la cryptographie post-quantique et le déchiffrement AES. Elle intéresse surtout les développeurs et les équipes qui intègrent OpenSSL à leurs logiciels.

Ces changements ne se traduiront pas par un nouveau bouton dans votre navigateur. Ils touchent les mécanismes qui établissent et protègent les communications, ainsi que le coût des calculs cryptographiques. Pour comprendre leur intérêt, il faut distinguer les nouveaux protocoles, les gains de performances ciblés et les adaptations nécessaires dans les applications.

Les principales nouveautés d’OpenSSL 4.1

• DTLS 1.3 : prise en charge de la version définie par la RFC 9147 pour sécuriser les communications par datagrammes.
• GREASE : support du mécanisme de la RFC 8701, destiné à préserver la capacité d’évolution de TLS.
• Cryptographie post-quantique : optimisations de ML-DSA et de certaines opérations ML-KEM, selon l’architecture du processeur.
• AES-CBC : accélération du déchiffrement sur x86-64 avec AVX-512 et VAES.
• API d’écoute : ajout de DTLS dans l’API SSL listener.
• Dérivation de clés : arrivée d’une implémentation IKEv2 KDF.
• Portabilité : premières bases de prise en charge de l’architecture Elbrus2000, appelée e2k.

La liste montre une version orientée vers l’intégration et l’efficacité. Les bénéfices dépendront des fonctions réellement utilisées : un logiciel qui ne fait pas de DTLS ne profitera pas directement de ce nouvel ajout, et une optimisation liée à des instructions processeur ne concerne pas toutes les machines.

DTLS 1.3 modernise la sécurité des communications par datagrammes

DTLS reprend les objectifs de sécurité de TLS dans un environnement où les données sont échangées sous forme de datagrammes, notamment avec UDP. Là où TLS accompagne couramment des connexions fiables, DTLS doit composer avec les particularités d’un transport qui ne garantit pas, à lui seul, la livraison ordonnée de tous les paquets.

La version 1.3 rapproche son fonctionnement des évolutions de TLS 1.3 : moins d’allers-retours pour établir la connexion et abandon d’anciens mécanismes cryptographiques. Elle peut aussi utiliser les algorithmes post-quantiques introduits dans OpenSSL 3.5. Le gain attendu porte donc autant sur l’établissement de la communication que sur sa modernisation.

Pour les développeurs, un point de migration mérite d’être souligné : DTLSv1_listen() ne prend pas en charge DTLS 1.3. Le projet indique que SSL_new_listener() accepte désormais DTLS. Une application existante doit donc examiner son code d’écoute, plutôt que considérer le changement de bibliothèque comme une adaptation complète.

C’est une distinction importante : disposer d’un protocole dans une bibliothèque ouvre une possibilité. Son utilisation effective demande encore que le logiciel l’intègre et que l’autre extrémité de la communication soit compatible.

GREASE aide TLS à accepter les évolutions futures

GREASE répond à un problème moins spectaculaire, mais bien réel : certains logiciels échouent lorsqu’ils rencontrent une valeur qu’ils ne connaissent pas dans une négociation TLS, alors qu’ils devraient pouvoir l’ignorer.

Le mécanisme utilise des valeurs réservées, volontairement sans fonction à négocier, pour exercer cette tolérance. Une implémentation correcte les ignore ; une implémentation trop rigide révèle son défaut. L’objectif est d’éviter que l’écosystème se fige autour des seules extensions déjà connues.

On peut le comparer à une vérification régulière de la place disponible pour ajouter de nouvelles options. Si personne ne rencontre jamais de valeur inconnue, un mauvais comportement peut rester longtemps invisible, puis bloquer le déploiement d’une véritable nouveauté.

GREASE n’est donc pas un nouvel algorithme de chiffrement. Son intérêt est l’interopérabilité et la possibilité de faire évoluer TLS sans casser des communications à cause de logiciels trop stricts.

Le post-quantique gagne en efficacité, sans promesse de gain universel

Les optimisations annoncées concernent notamment les calculs NTT de ML-DSA et ML-KEM sur ppc64le, ML-DSA sur x86-64, et des opérations SHAKE traitées par lots avec AVX-512. ML-DSA sert à la signature numérique ; ML-KEM à l’établissement d’un secret partagé par encapsulation de clé.

Le travail porte ici sur la manière d’exécuter ces algorithmes plus efficacement. Il ne signifie pas que toutes les connexions deviennent automatiquement post-quantiques après une installation. Leur protection dépend aussi des algorithmes sélectionnés et négociés par les applications.

Le même raisonnement s’applique aux optimisations AES-CBC : elles visent un traitement et des capacités matérielles précis. Sans benchmark correspondant à votre charge de travail, je ne donnerais aucun pourcentage de gain. Une accélération du déchiffrement AES-CBC ne permet pas non plus de conclure que tous les échanges TLS seront plus rapides.

Une migration à préparer selon les besoins de ses logiciels

Quelques changements concernent directement la compilation et les outils : tsget passe de WWW::Curl::Easy à Net::Curl::Easy, les cibles Windows CE et Windows sur Itanium disparaissent, et les options no-ecdsa et no-ecdh sont retirées. Les scripts qui s’appuient sur ces éléments devront être revus.

OpenSSL 4.1 est une version non LTS, dont la fin de support annoncée se situe en novembre 2027. La branche 3.5 LTS reste, elle, annoncée comme maintenue jusqu’au 8 avril 2030. Le numéro le plus élevé ne constitue donc pas, à lui seul, un critère suffisant pour choisir une branche en production.

Je privilégierais une décision fondée sur les besoins : DTLS 1.3 ou une optimisation pertinente peuvent justifier une évaluation de la 4.1. Pour un serveur administré via les paquets d’une distribution, il faut également tenir compte du support de celle-ci et des dépendances applicatives, plutôt que remplacer manuellement la bibliothèque système.

Cette sortie fournit des briques utiles pour moderniser les communications chiffrées. Leur intérêt se concrétisera avec leur adoption dans les logiciels, les tests d’interopérabilité et les mesures sur les matériels concernés.