OpenSSL 4.1 ajoute DTLS 1.3 et GREASE au chiffrement des connexions UDP

9 septembre 2026. OpenSSL publie la première alpha de sa version 4.1, et le contenu du changelog ressemble à une mise à niveau de fond plutôt qu’à une simple itération : DTLS 1.3 arrive enfin dans la bibliothèque, GREASE y fait son entrée, et les optimisations AVX-512 s’étendent à la cryptographie post-quantique. Pourquoi c’est important : OpenSSL chiffre une part considérable du trafic mondial — serveurs web, appliances réseau, VPN, objets connectés — et ce que sa branche stable adopte aujourd’hui devient la ligne de base de demain.

DTLS 1.3, le chaînon manquant d’OpenSSL

DTLS est la déclinaison de TLS pour les transports non fiables : là où TCP garantit l’ordre et la retransmission, DTLS doit fonctionner sur UDP, où les paquets peuvent arriver dans le désordre, être perdus ou dupliqués. C’est le protocole des communications en temps réel — VoIP, WebRTC, gaming, télémétrie IoT — et il était resté figé sur la version 1.2 dans l’écosystème OpenSSL.

DTLS 1.3, normalisé par le RFC 9147, aligne enfin DTLS sur les acquis de TLS 1.3. Les gains sont concrets. Le handshake passe à un seul aller-retour dans le cas nominal, au lieu du double échange imposé par la version 1.2 avec son mécanisme de cookie anti-amplification : pour un capteur qui se réveille sur un réseau cellulaire, chaque milliseconde économisée compte. La forward secrecy devient la règle, là où DTLS 1.2 laissait encore la place à des suites reposant sur un échange de clés statique. Et l’en-tête est réorganisé pour se rapprocher du format compact de TLS 1.3.

Le point qui change la donne à moyen terme : DTLS 1.3 intègre nativement les mécanismes de cryptographie post-quantique. Là où DTLS 1.2 exigeait des bricolages pour acheminer des clés ML-KEM ou ML-DSA dans des extensions, la version 1.3 les accepte comme citoyens de première classe. Pour une passerelle IoT déployée pour dix ans, cette différence est stratégique : elle détermine si l’équipement pourra négocier des algorithmes résistants à un ordinateur quantique sans remplacement matériel.

GREASE, ou l’art d’empêcher le protocole de se figer

La seconde nouveauté porte un nom étrange qui cache un mécanisme malin. GREASE, pour Generate Random Extensions And Sustain Extensibility, vient du RFC 8701 et a été popularisé par Google dans Chrome. Le principe : un client GREASE insère, dans son handshake TLS, des valeurs aléatoires et dénuées de sens pour des identifiants de suites, d’extensions ou de groupes qui ne seront jamais réellement utilisés.

L’objectif n’est pas de chiffrer davantage, mais de détecter les implémentations non conformes. Un serveur ou un middlebox correctement écrit doit ignorer ces valeurs inconnues et poursuivre la négociation. Celui qui les rejette en fermant la connexion — ou pire, qui tente de les interpréter — révèle immédiatement son manque de robustesse. À grande échelle, GREASE transforme le réseau en banc de test permanent : il force chaque extrémité à tolérer l’inconnu, ce qui empêche l’ossification du protocole.

L’enjeu est plus politique que technique. Les protocoles réseau meurent quand les boîtiers intermédiaires — firewalls, load balancers, NAT — s’habituent à un comportement précis et rejettent tout écart. C’est exactement ce qui a ralenti l’adoption de TLS 1.3 sur le terrain : des équipements qui décrochaient dès qu’une extension inconnue apparaissait. En embarquant GREASE dans OpenSSL, la bibliothèque qui équipe la plupart de ces boîtiers, on attaque le problème à la source : chaque appareil qui se met à jour participe, sans le savoir, à rendre l’écosystème plus souple pour les prochaines évolutions.

La post-quantique accélérée par AVX-512

Le troisième volet de cette alpha est plus silencieux mais tout aussi structurant : OpenSSL 4.1 optimise AVX-512 pour SHAKE en mode x4, au service de ML-DSA. ML-DSA est l’algorithme de signature post-quantique retenu par le NIST dans FIPS 204 ; il repose sur les fonctions de hachage SHAKE, dont le coût en calcul était jusqu’ici un frein à l’adoption. Le déploiement des signatures post-quantiques se heurte à une réalité d’exploitation : signer un certificat ou une poignée de main avec ML-DSA coûte nettement plus cher qu’avec RSA ou ECDSA, en cycles CPU comme en latence.

Les optimisations AVX-512 de cette alpha attaquent précisément ce goulot sur x86_64. À cela s’ajoutent des accélérations AES et AVX-512 pour le déchiffrement AES-CBC, un mode encore massivement présent dans les flux hérités et les appliances. Le message d’ensemble est clair : la post-quantique cesse d’être une option de laboratoire pour devenir un enjeu de performance, et OpenSSL traite ce sujet comme une contrainte de production, pas comme un exercice académique.

La version tourne aussi la page sur des cibles mortes — fin du support de Windows sur Itanium et de Windows CE — tout en ajoutant un premier support pour l’architecture Elbrus 2000 « E2K ». Ce tri des plateformes, banal en apparence, concentre les efforts d’optimisation sur les architectures qui comptent réellement dans les datacenters et les équipements réseau.

Ce que ça change pour les opérateurs

Cette alpha n’est pas à déployer en production — c’est une version de test, et OpenSSL lui-même invite à la benchmarker, pas à la mettre en service. Mais elle fixe le cap de la branche 4.1 et déclenche une question concrète pour toute équipe qui exploite du UDP chiffré.

Si vous maintenez des services temps réel — VoIP, WebRTC, passerelles IoT, VPN sur UDP — recensez dès maintenant les composants encore bloqués en DTLS 1.2. La migration vers DTLS 1.3 ne se fera pas par simple montée de version : il faudra vérifier la compatibilité des middleboxes et des clients tiers, exactement le genre de chantier où GREASE révèle tôt les équipements récalcitrants.

Si vous gérez un parc de boîtiers réseau — firewalls, load balancers, concentrateurs VPN — assurez-vous qu’ils tolèrent les valeurs GREASE inconnues. Un boîtier qui échoue au test GREASE est un boîtier qui cassera la prochaine évolution de TLS, et le corriger coûte bien moins cher aujourd’hui qu’au moment où vos clients constateront l’échec des négociations en production.

Si vous planifiez la post-quantique, suivez l’évolution des performances ML-DSA sous AVX-512 : c’est un bon indicateur de ce que coûtera, en CPU, la migration de vos chaînes de signature une fois que les régulateurs imposeront des horloges fermes. Les gains annoncés ici détermineront si cette migration tient sur votre matériel actuel ou exige un rafraîchissement.

Enfin, notez que cette alpha arrive dans un contexte où les piles alternatives — BoringSSL, rustls — ont déjà comblé une partie du retard en DTLS 1.3. La valeur d’OpenSSL 4.1 n’est pas d’être pionnier, mais de rendre ces capacités disponibles dans la bibliothèque par défaut, là où des milliers d’équipements les attendent sans avoir à changer de pile.

Verdict

OpenSSL 4.1 ne résout pas un incident, il prépare une infrastructure. La combinaison DTLS 1.3, GREASE et AVX-512 post-quantique en fait la version la plus structurante de la bibliothèque depuis l’arrivée de TLS 1.3 dans la branche 1.1.1. Pour un opérateur réseau, la bonne réaction n’est pas d’attendre la GA : c’est d’utiliser cette alpha comme un plan de test, de lancer GREASE sur son parc et d’identifier les équipements qui ne survivront pas à la prochaine négociation. Ceux qui auront traité ces signaux en amont migreront en une soirée ; les autres découvriront leurs middleboxes cassées un matin de mise à jour forcée.

Références

• Phoronix — OpenSSL 4.1 Alpha 1 Released With DTLS 1.3, GREASE & More AVX-512 Optimizations, 9 septembre 2026
• RFC 9147 — The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
• RFC 8701 — Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility
• NIST — FIPS 204, Module-Lattice-Based Digital Signature Standard (ML-DSA)