Rustls 0.23.45 corrige une faille TLS 1.3 datant de 2024

Rustls 0.23.45 est sorti le 14 septembre 2026 avec un correctif pour un bogue de poignée de main TLS 1.3 présent dans du code publié depuis environ deux ans. Toutes les versions de 0.23.13 à 0.23.44 sont concernées. Quiconque dépend de Rustls devrait donc vérifier la version que sa compilation résout réellement. Phoronix a rendu compte de la sortie, et le projet a déposé les détails sous l'avis GHSA-2mjx-qc3c-rqvc.

Rustls est une bibliothèque TLS écrite en Rust. TLS est le protocole derrière HTTPS, et une bibliothèque TLS est ce que votre programme utilise pour établir une connexion chiffrée. Rustls est un choix courant dans les services Rust qui veulent éviter OpenSSL.

Ce que la faille permet réellement

Au milieu d'une poignée de main TLS 1.3, les deux parties changent de clés. Les messages envoyés après ce changement doivent être chiffrés avec la nouvelle clé. Rustls ne l'imposait pas toujours.

L'avis précise la condition. Rustls acceptait des messages de poignée de main envoyés au mauvais niveau de chiffrement lorsqu'ils suivaient un message changeant les clés dans le même enregistrement. Un enregistrement est le bloc que le protocole place réellement sur le réseau, donc plusieurs messages de poignée de main peuvent voyager ensemble.

Lue honnêtement, la portée est plus étroite qu'il n'y paraît. « La transcription de la poignée de main reste authentifiée », indique l'annonce. Un attaquant en position réseau ne peut donc pas s'en servir pour modifier une poignée de main ni en conclure une qu'il ne devrait pas. L'effet pratique est qu'un pair pouvait envoyer en clair ce que le protocole exige de chiffrer, sans que Rustls rejette la connexion.

C'est donc un bogue de rigueur, pas un contrôle d'authentification cassé. Cela compte tout de même. Une bibliothèque qui accepte des messages interdits par la spécification s'écarte du RFC 8446, et c'est de ces écarts que naissent les bogues d'interopérabilité et les attaques ultérieures.

La sûreté mémoire n'a jamais été tout le travail

Phoronix en tire la conclusion utile, et elle mérite d'être dite clairement. Rustls existe en partie parce que le code TLS non sûr en mémoire a une longue histoire de bogues graves, et Rust supprime cette classe de défauts. Ce bogue n'appartient pas à cette classe.

Rien dans Rust n'empêche un automate de protocole d'accepter un message qu'il aurait dû refuser. C'est une erreur de logique, et les erreurs de logique survivent à tout choix de langage. Une réécriture dans un langage sûr vous affranchit des débordements de tampon et des usages après libération, pas d'une mauvaise lecture de la spécification.

Ce site a fait le même constat dans l'autre sens : un paquet Rust a servi de véhicule à une attaque de chaîne d'approvisionnement à la compilation sur arrayref. Le langage est une couche de défense, et une seule.

Les versions à vérifier

Version	Statut
0.23.13 à 0.23.44	Concernée
0.23.45	Corrigée
Avant 0.23.13	Antérieure au changement ayant introduit le bogue, selon l'avis

Le bogue a été introduit en septembre 2024, ce qui explique que la plage concernée commence à 0.23.13 et non au début. Le problème est aussi suivi sous l'identifiant GO-2026-4340.

Ce que cela signifie pour les développeurs

Mettez à jour, puis découvrez ce que vous exécutiez vraiment. Ce sont deux tâches distinctes, et c'est la seconde que l'on saute.

Lancez cargo update -p rustls et vérifiez que vous arrivez en 0.23.45 ou plus récent. Lancez ensuite cargo tree -i rustls pour voir ce qui l'a amené. Rustls est en général une dépendance indirecte, arrivant via un client HTTP ou un cadriciel serveur. La version que vous obtenez est donc décidée par ce que ces caisses autorisent. Une épingle transitive dans une bibliothèque que vous ne contrôlez pas est la raison habituelle pour laquelle une mise à jour semble ne rien faire.

Si vous livrez un binaire plutôt qu'un service, vérifiez le fichier de verrouillage à partir duquel vous avez réellement compilé, pas celui présent aujourd'hui sur votre machine. Brancher cargo audit dans l'intégration continue vaut la peine, que ce bogue vous concerne ou non, et l'outil signalera l'avis dès que sa base de données le contiendra.

Ne passez pas l'après-midi en réponse à incident pour autant. Aucune des deux sources n'évoque d'exploitation, et l'avis lui-même dit que la transcription reste authentifiée, ce qui écarte la lecture la plus inquiétante. Traitez cela comme une montée de dépendance ordinaire avec une véritable échéance, pas comme une urgence.

La leçon plus large porte sur la durée de vie d'un bogue de protocole silencieux. Celui-ci est resté deux ans dans des versions livrées, dans une bibliothèque choisie précisément pour ses propriétés de sûreté, et il a été trouvé par relecture et non par un incident. C'est le système qui fonctionne. C'est aussi un rappel que « écrit en Rust » est une affirmation sur une catégorie de bogues, et sur rien d'autre.