OpenSSL 4.1.0 livre enfin DTLS 1.3, avec quatre bugs connus dans le code livré
Le 23 octobre 2026, OpenSSL publie la version 4.1.0, qui apporte le support de DTLS 1.3 (RFC 9147) en même temps que quatre bugs connus dans ce code, dont deux font mentir les codes de retour d’une connexion. Si vous adoptez DTLS 1.3 côté serveur, ne prenez pas SSL_ERROR_WANT_READ ni SSL_ERROR_SYSCALL au pied de la lettre.
23 octobre 2026. OpenSSL publie la version stable 4.1.0, qui ajoute le support de DTLS 1.3, la version du protocole de transport sécurisé pensée pour les datagrammes UDP, définie par la RFC 9147. 23 octobre 2026, même jour. La note de version liste quatre bugs connus dans ce code DTLS, sans statut de correctif pour trois d’entre eux. 26 octobre 2026. Help Net Security détaille comment deux de ces bugs font mentir les codes de retour renvoyés aux applications. Le point clé : DTLS 1.3 arrive avec de vrais gains, mais aussi avec des pièges documentés qui attendent les premiers à l’adopter côté serveur.
Pour qui fait tourner des VPN, du WebRTC, de la voix ou de l’IoT sur UDP, c’est une mise en garde utile : la nouveauté est réelle, mais elle se paie pour l’instant d’une machine à états qui ne dit pas toujours la vérité.
DTLS 1.3 arrive, quatre ans après TLS 1.3
TLS 1.3 a été normalisé en 2018 ; son pendant datagramme, DTLS 1.3, a mis des années de plus à arriver dans OpenSSL. L’écart n’est pas anodin : DTLS doit reconstruire sur UDP — sans ordre garanti, sans fiabilité, avec pertes et duplications possibles — les garanties que TLS obtient presque gratuitement sur TCP. C’est cette couche de retransmission et de gestion des pertes qui concentre aujourd’hui les bugs.
Les bénéfices annoncés sont concrets. DTLS 1.3 apporte un handshake nettement plus rapide, la forward secrecy, un format d’en-tête optimisé, et un support intégré de la cryptographie post-quantique — ML-KEM et ML-DSA — qui compte pour les équipements à longue durée de vie. Phoronix note aussi que 4.1.0 embarque des optimisations AVX-512 pour ML-DSA (SHAKE x4) et pour le déchiffrement AES-CBC, ainsi que GREASE (RFC 8701), qui envoie des valeurs aléatoires réservées dans les handshakes pour débusquer les serveurs qui gèrent mal l’inconnu.
Les consommateurs de DTLS sont précisément ceux qui ressentent le plus la latence de handshake : le WebRTC des appels vidéo, les VPN sur UDP, la téléphonie, la diffusion en direct et une large part de l’IoT industriel. Pour eux, un handshake plus court n’est pas un détail : c’est le temps avant que l’appel sonne, que le tunnel monte ou que le capteur réponde. C’est aussi pour ces équipements à longue durée de vie que le support intégré de ML-KEM et ML-DSA compte — un objet déployé dix ans doit pouvoir négocier du post-quantique sans mise à niveau matérielle.
Quatre bugs connus, deux qui font mentir la machine à états
Les quatre bugs listés par le projet sont documentés, pas spéculatifs. Deux d’entre eux touchent la façon dont OpenSSL rapporte l’état d’une connexion à l’application qui l’utilise.
Le premier : un échec de réception permanent sur un listener DTLS peut remonter sous la forme de SSL_ERROR_WANT_READ, le code qui dit au programme « attends plus de données ». Le piège est double : l’interrogation par polling puis l’appel à accept peuvent rater l’erreur eux aussi, laissant l’application attendre indéfiniment sur une connexion déjà morte. Une connexion fantôme qui ne se referme jamais, c’est un descripteur qui fuit et un service qui semble vivant alors qu’il ne l’est plus.
Le second : un échec d’écriture réessayable sur une connexion non bloquante acceptée peut remonter sous la forme de SSL_ERROR_SYSCALL. Une application qui traite ce code comme fatal — ce que font la plupart des implémentations — fermera une connexion qui, en réalité, fonctionne encore. Là, c’est l’inverse : une connexion saine qu’on tue par excès de prudence.
La consigne du projet est explicite : le code qui accepte des connexions depuis un listener DTLS ne doit pas prendre SSL_ERROR_WANT_READ ni SSL_ERROR_SYSCALL pour argent comptant tant que ces deux bugs ne sont pas corrigés.
Ces deux bugs mordent surtout les serveurs à boucle d’événements non bloquante — Node.js, nginx, tout serveur écrit autour de libuv ou d’une machine à états réactive — où SSL_ERROR_WANT_READ est traité comme un signal normal de « reviens plus tard » et SSL_ERROR_SYSCALL comme une erreur à propager. Sur ce type de code, le premier bug laisse une connexion zombie accrochée à la boucle, le second fait tomber des connexions vivantes. Un serveur DTLS classique en threads bloquants y est moins exposé, mais reste concerné par les deux bugs de handshake.
Handshakes avortés et tickets perdus
Les deux autres bugs concernent la négociation elle-même. Un serveur DTLS 1.3 peut avorter un handshake avec une alerte unexpected_message lorsque le client accuse réception d’une partie ou de la totalité du premier vol du serveur avant de répondre — une situation qui survient typiquement après une perte de paquet. En clair, un réseau qui perd un paquet peut transformer une négociation parfaitement légitime en échec.
Le quatrième implique KeyUpdate, le message qu’un pair envoie pour basculer vers de nouvelles clés en cours de session. Quand OpenSSL en reçoit un, il vide son tampon de retransmission de tous les autres enregistrements post-handshake en attente. Si un NewSessionTicket — qui permet au client de reprendre la session plus tard — a été perdu lors de son premier envoi, OpenSSL ne le renverra pas. La reprise de session devient alors silencieusement impossible. Pour ce bug, un correctif est en cours ; pour les trois autres, aucun statut n’est annoncé.
Ce qui part et ce qui casse au passage
La version 4.1.0 ne fait pas qu’ajouter. Elle retire les options no-ecdsa et no-ecdh de Configure, parce qu’elles ne désactivaient pas réellement les implémentations qu’elles nommaient : un binaire compilé avec ces drapeaux embarquait quand même le code censé être exclu. Le projet renvoie vers no-ec, qui désactive tout le support des courbes elliptiques. C’est une correction de sémantique, mais elle cassera les scripts de build qui comptaient sur l’ancienne illusion.
Deux autres changements peuvent casser l’existant. OpenSSL abandonne les cibles Windows-on-Itanium et Windows CE, et l’utilitaire d’horodatage tsget exige désormais le module Perl Net::Curl::Easy, en remplacement de l’abandonné WWW::Curl::Easy. Quiconque s’appuie sur tsget doit installer le nouveau module avant la mise à niveau.
Reste un vrai progrès à saluer : le guide DTLS 1.3 est livré sous forme de page de manuel ossl-guide-dtlsv13(7), ce qui contraste avec la documentation souvent lacunaire des précédentes nouveautés cryptographiques.
Au-delà des bugs de DTLS, la sortie 4.1.0 rappelle une règle d’exploitation simple : une mise à niveau majeure d’une bibliothèque cryptographique se teste contre son propre trafic, pas seulement contre les tests unitaires du projet. Les quatre bugs connus auraient été visibles dans un harnais qui exerce la perte de paquets et les KeyUpdate — deux scénarios que la plupart des bancs d’essai d’OpenSSL ne couvrent pas.
Verdict
Si vous faites tourner un serveur DTLS 1.3 en production, traitez cette version comme une sortie à adopter avec un garde-fou : ne prenez pas SSL_ERROR_WANT_READ ni SSL_ERROR_SYSCALL au pied de la lettre tant que les deux bugs de machine à états ne sont pas corrigés, et prévoyez une supervision qui détecte les connexions fantômes. Si vous n’avez pas de raison forte de migrer — post-quantique, handshake plus rapide — restez sur DTLS 1.2, mûr et sans bug documenté dans cette version, et attendez le correctif du bug KeyUpdate. La leçon vaut au-delà d’OpenSSL : un protocole nouveau peut être livré avec ses défauts consignés noir sur blanc, et le travail d’un exploitant n’est pas de courir après la nouveauté, mais de lire la note de version avant de la déployer.