Douze ans après Heartbleed, OpenSSL 4.0 enterre SSLv3, chiffre le SNI et embrasse le post-quantique : OpenSSL 4.0 s'attaque au filtrage d'État et à l'inspection de trafic en entreprise

Douze ans après Heartbleed, OpenSSL 4.0 enterre SSLv3, chiffre le SNI et embrasse le post-quantique :
OpenSSL 4.0 s'attaque au filtrage d'État et à l'inspection de trafic en entreprise

Publiée par Matt Caswell au nom de l'OpenSSL Foundation, la version 4.0.0 de la bibliothèque cryptographique OpenSSL marque un tournant net dans l'histoire du projet. Entre nettoyage radical du code hérité, support tant attendu de l'Encrypted Client Hello et intégration de la cryptographie post-quantique standardisée par le NIST, cette livraison est bien plus qu'une simple mise à jour de numéro de version. Elle engage aussi une rupture franche avec une décennie de dettes techniques accumulées depuis Heartbleed et repose, une fois encore, la question de la gouvernance d'une infrastructure invisible mais vitale pour l'ensemble de l'internet.

OpenSSL 4.0.0 supprime le support de SSLv3, déprécié depuis 2015 et désactivé par défaut depuis la version 1.1.0 en 2016, ainsi que celui du SSLv2 Client Hello. Ces vestiges d'une ère révolue traînaient dans la base de code comme autant de rappels que la bibliothèque avait longtemps fait passer la compatibilité descendante avant l'hygiène technique.

Plus significative encore est la suppression définitive du support des "engines", le mécanisme historique qui permettait d'étendre OpenSSL via des modules tiers. Ce système, progressivement remplacé depuis OpenSSL 3.0 par une architecture de "providers" plus moderne, cristallisait depuis des années les critiques des mainteneurs de distributions. Du côté de Fedora, les dépendances sur les engines avaient déjà été pour la plupart migrées, ce qui rend la transition vers la 4.0 comparativement plus fluide que le passage de la 1.x à la 3.0 en son temps.

Les changements d'API sont substantiels. Le type ASN1_STRING est désormais opaque, de nombreuses fonctions liées au traitement X.509 ont vu leurs signatures modifiées pour introduire des qualificatifs const, et les fonctions de comparaison temporelle X509_cmp_time() et X509_cmp_current_time() sont dépréciées au profit de X509_check_certificate_times(). Pour les développeurs qui intègrent OpenSSL dans des projets tiers, ces changements nécessitent une révision minutieuse du code existant et les compilateurs silencieux ne suffiront pas à détecter toutes les régressions.

Des changements comme l'opacification de ASN1_STRING peuvent conduire à des segfaults en production sur du code qui compilait pourtant sans avertissement. Le conseil vaut son pesant d'or : activer -Werror=deprecated-declarations et faire tourner AddressSanitizer en intégration continue avant toute bascule.

ECH : la confidentialité du handshake TLS, enfin

La fonctionnalité la plus attendue de cette version est incontestablement le support de l'Encrypted Client Hello (ECH), désormais standardisé sous la référence RFC 9849. ECH est une extension de sécurité TLS qui permet de chiffrer le message initial "Client Hello" du handshake, masquant ainsi l'indication du nom de serveur (SNI) pour éviter que le nom d'hôte de destination ne soit visible en clair sur le réseau.

Jusqu'à présent, même sur une connexion HTTPS, un observateur sur le réseau (qu'il s'agisse d'un fournisseur d'accès, d'un employeur ou d'un État) pouvait identifier le site cible d'une requête grâce au SNI transmis en clair lors de l'établissement de la connexion TLS. ECH vient colmater cette brèche structurelle.

La bonne nouvelle : Cloudflare supporte ECH depuis 2023, Firefox l'active par défaut depuis sa version 119, et Chrome le prend également en charge. Safari reste à la traîne : Apple expose bien une option expérimentale au niveau du système d'exploitation, mais elle n'est pas encore activable simplement dans le navigateur ; la situation devrait vraisemblablement évoluer avec les sorties de l'automne 2026.

Sur le plan serveur, Nginx mainline 1.29.x supporte déjà ECH, mais son déploiement réel dans les distributions grand public prendra du temps : la fenêtre est probablement manquée pour Ubuntu 26.04, et Debian 14 constitue une cible plus réaliste pour l'année prochaine.

Il convient néanmoins de nuancer l'enthousiasme. Sur un serveur personnel ou une infrastructure à faible diversité d'hébergement, ECH n'apporte qu'un bénéfice limité : un adversaire peut toujours corréler l'adresse IP aux sites hébergés. Le gain réel est surtout perceptible sur les grandes plateformes mutualisées, où des milliers de domaines cohabitent sur une même IP.

Il faut aussi mentionner une friction opérationnelle : le déploiement d'ECH côté serveur requiert la publication de clés publiques ECH dans des enregistrements DNS de type HTTPS, ce qui implique une coordination avec les équipes DNS, une dépendance non triviale dans les organisations de taille intermédiaire.


ECH face aux censeurs et aux pare-feux d'entreprise : la guerre a déjà commencé

ECH n'est pas une innovation accueillie avec le même enthousiasme par tous les acteurs du réseau. Pour les États qui pratiquent la censure par filtrage SNI, pour les entreprises qui s'appuient sur l'inspection du trafic sortant, et pour les éditeurs de solutions de sécurité réseau, ECH constitue une menace directe contre des mécanismes de contrôle établis depuis deux décennies. La réponse n'a pas tardé.

En novembre 2024, la Russie a commencé à bloquer l'implémentation ECH de Cloudflare. Le régulateur russe de l'internet a justifié cette décision en qualifiant ECH de « moyen de contournement des restrictions d'accès à l'information interdite en Russie », dont l'usage « viole la loi russe ». La Chine et l'Iran n'ont pas attendu non plus. Des chercheurs ont montré, dans une étude publiée début 2025, que ces deux pays ont contourné ECH non pas en bloquant le protocole lui-même, mais en censurant le DNS chiffré qui permet de le distribuer, déplaçant ainsi le point de contrôle plutôt que de chercher à briser le chiffrement. Autrement dit, ECH ne résout pas le problème de la censure par SNI : il le déplace.

Ce mécanisme de déplacement est précisément ce qui rend ECH à la fois prometteur et fragile. En cas de blocage du DNS, ECH se replie silencieusement sur un handshake classique avec le SNI visible en clair ; ce comportement est intentionnel, ECH étant conçu comme une amélioration de la confidentialité, pas comme un prérequis à la connectivité. Mais dans les environnements de censure, ce repli signifie que bloquer l'enregistrement DNS HTTPS suffit à désactiver ECH.

L'histoire du filtrage SNI a une date de naissance précise : février 2019, lorsque la Corée du Sud a discrètement déployé, en coordination avec les fournisseurs d'accès locaux, un système d'inspection SNI pour bloquer les domaines interdits par la Commission des standards de communication, contournant ainsi les techniques de blocage DNS que les utilisateurs avertis savaient déjà éviter. Ce précédent a inspiré d'autres gouvernements et montré à quel point le SNI en clair constituait un outil de censure commode, disponible sans investissement technique majeur.

Du côté des entreprises et des opérateurs réseau, la réaction est tout aussi révélatrice. Cisco a introduit dans son pare-feu Secure Firewall, à partir d'octobre 2025, un détecteur applicatif baptisé « ECH Servers » permettant d'identifier les connexions vers les CDN connus pour offrir ECH, afin de surveiller le volume de ce trafic et d'élaborer des politiques ciblées. La documentation de Cisco est prudente sur le blocage pur : bloquer les points de terminaison des CDN compatibles ECH provoque des échecs de connexion et des délais d'attente prolongés selon les navigateurs, certains refusant de se replier sur un SNI en clair, d'autres accumulant jusqu'à deux minutes de tentatives avant d'abandonner.

Le blog technique de l'APNIC résume le défi pour les organisations : en activant ECH, les CDN déplacent le point de contrôle du contenu vers le navigateur, rendant les listes d'autorisation et de blocage traditionnelles moins efficaces, et laissant le filtrage DNS et les fonctions de navigation sécurisée comme principaux outils restants. Pour les équipes de sécurité des entreprises habituées à inspecter passivement le SNI, c'est une remise en cause profonde. L'inspection passive (sur port miroir ou en écoute réseau) est complètement aveuglée par ECH : le SNI visible dans le ClientHello extérieur est un domaine de couverture générique, non la destination réelle. Seul un proxy L7 qui termine et réinitialise la connexion TLS conserve la visibilité sur le trafic.

La concentration du déploiement ECH autour de Cloudflare pose par ailleurs une question de gouvernance rarement formulée explicitement. Début 2025, parmi les serveurs du classement Tranco Top 1 Million supportant ECH, la quasi-totalité passaient par l'infrastructure Cloudflare, six serveurs seulement avaient déployé une configuration ECH indépendante. ECH, dans sa forme actuelle, est donc moins une décentralisation de la confidentialité qu'une délégation de celle-ci à un acteur privé dominant. Contourner la censure par SNI revient, en pratique, à faire confiance à Cloudflare pour ne pas exercer sa propre forme de contrôle sur les destinations qu'elle dessert.

ECH cible aussi les incitations économiques et politiques derrière la censure systémique : sur un grand CDN, une seule adresse IP dessert des centaines de sites. Un censeur qui se trompe de cible et bloque une IP populaire subit un coût politique et économique immédiat, ce qui crée une friction naturelle contre le blocage grossier. C'est peut-être là l'effet le plus durable d'ECH : non pas rendre la censure impossible, mais la rendre coûteuse.


Cryptographie post-quantique : ML-DSA et SM2 entrent en scène

Au-delà d'ECH, OpenSSL 4.0 consolide le virage post-quantique amorcé par les versions précédentes. Cette version intègre le support de l'algorithme de signature ML-DSA-MU, ainsi que du groupe hybride post-quantique curveSM2MLKEM768 conformément au projet de standard tls-hybrid-sm2-mlkem.

Le contexte est celui de l'urgence rampante des attaques dites "harvest now, decrypt later" : des adversaires collectent dès aujourd'hui des flux chiffrés avec les algorithmes classiques (RSA, courbes elliptiques standard) en pariant sur leur déchiffrement futur une fois que les ordinateurs quantiques auront atteint une puissance suffisante. Le NIST a finalisé ses standards post-quantiques en août 2024 (notamment ML-DSA (Dilithium) pour les signatures, ML-KEM (Kyber) pour l'échange de clés) et leur intégration dans OpenSSL les rend maintenant accessibles en production.

La version 4.0 ajoute également le support de cSHAKE conformément à la spécification SP 800-185 du NIST, des fonctions de dérivation de clés pour SNMP KDF et SRTP KDF, et le support de l'échange de clés FFDHE négocié en TLS 1.2 (RFC 7919).

La version 3.0 reste dans les mémoires comme un traumatisme

OpenSSL 4.0 arrive dans un écosystème encore marqué par les séquelles d'OpenSSL 3.0. Le bilan de cette version reste particulièrement sévère dans la communauté. Selon le chercheur en sécurité Thomas Ptacek, si les pratiques de sécurité d'OpenSSL se sont nettement améliorées depuis Heartbleed, la qualité logicielle a paradoxalement régressé avec la 3.0, dont la conception est largement perçue comme un recul (notamment en termes de performances) au point où des projets majeurs comme pyca/cryptography envisagent activement de migrer vers d'autres bibliothèques.

Le diagnostic est documenté. Les équipes de pyca/cryptography ont publié une analyse pointant les performances de chiffrement d'OpenSSL 3.x entre 10 % et 99 % inférieures à celles de la version 1.1.1, une régression directement imputable à l'introduction de structures de données dynamiques là où des constantes fixes suffisaient auparavant, avec le coût en verrous associé. HAProxy Technologies a de son côté publié un état des lieux comparatif des bibliothèques SSL qui n'est guère tendre avec l'implémentation actuelle d'OpenSSL.

La question centrale reste : OpenSSL 4.0 corrige-t-il vraiment ce qui était cassé dans la 3.0 ? Les notes de version ne mentionnent pas explicitement de remise à plat de l'architecture interne héritée de cette version, les suppressions de code légacy sont réelles, mais les goulots d'étranglement de performance pointés par les utilisateurs intensifs (HAProxy, curl, les wrappers Python) semblent non adressés dans ce cycle.


Heartbleed, douze ans après : le fantôme qui hante encore le projet

Pour comprendre où en est OpenSSL aujourd'hui, il faut revenir à avril 2014. La divulgation de la faille CVE-2014-0160, rapidement baptisée Heartbleed par des chercheurs de la société de sécurité informatique Codenomicon (notamment Riku, Antti et Matti) et par Neel Mehta de l'équipe Google Security, provoque un séisme dans l'industrie. Le principe de l'attaque est d'une simplicité redoutable : une implémentation défaillante de l'extension Heartbeat du protocole TLS permet à un attaquant d'envoyer une requête malformée et d'obtenir en retour jusqu'à 64 Ko de mémoire vive du serveur ciblé... sans authentification, sans journal, sans trace. Clés privées, mots de passe, cookies de session, tout ce qui transitait en mémoire au moment de l'attaque était potentiellement accessible. Et ce, depuis deux ans sans que personne ne s'en soit rendu compte.

L'onde de choc révèle quelque chose de plus profond que la faille elle-même : OpenSSL, bibliothèque cryptographique embarquée dans les deux tiers des serveurs HTTPS de la planète à l'époque, est maintenue par une poignée de développeurs, dont un seul à temps plein, avec un budget annuel de quelques dizaines de milliers de dollars. L'internet mondial repose sur une infrastructure critique financée comme un projet de hobbyiste.

La réponse de l'écosystème est immédiate et multiforme. La Core Infrastructure Initiative (CII), lancée sous l'égide de la Linux Foundation avec le soutien de Google, Microsoft, Amazon et d'autres géants du secteur, débloque des financements substantiels pour OpenSSL et d'autres projets jugés critiques. L'équipe de développement se renforce. Les audits de code se multiplient. L'OpenBSD Foundation, fidèle à sa tradition de sécurité offensive, fork carrément la bibliothèque pour donner naissance à LibreSSL, avec pour objectif déclaré d'expurger des centaines de milliers de lignes de code jugées dangereuses ou inutiles.

C'est dans ce contexte post-traumatique qu'OpenSSL 1.0.2, puis 1.1.0, puis la série 3.x ont été développées, chaque version cherchant à corriger non seulement les vulnérabilités connues, mais aussi les pratiques qui les avaient rendues possibles : gestion mémoire, modularité, tests. Le résultat sur le plan de la sécurité est tangible : OpenSSL est aujourd'hui l'une des cibles les plus scrutées de l'internet, couverte par des dizaines de chercheurs, des programmes de bug bounty et des audits commandités. Aucune vulnérabilité critique comparable à Heartbleed n'a depuis lors été découverte dans la bibliothèque principale.

Mais Heartbleed a laissé une autre cicatrice, moins visible : celle d'une réforme architecturale menée dans l'urgence et sous pression politique. La transition vers OpenSSL 3.0, censée moderniser l'ensemble de la base de code en introduisant le modèle de "providers" et une abstraction généralisée des algorithmes, a été vécue par une partie de la communauté comme un remède pire que le mal. Des systèmes de verrous introduits pour sécuriser les accès concurrents à des structures désormais dynamiques ont dégradé les performances de façon spectaculaire. Les anciens utilisateurs de la série 1.1.1, dont HAProxy et plusieurs projets Python, ont vu leurs benchmarks se dégrader sur des opérations aussi fondamentales que la dérivation de clés ou l'établissement de sessions TLS.

OpenSSL 4.0 tente de tourner une nouvelle page sans pour autant faire table rase de cette architecture 3.x. La suppression des engines, l'opacification des types internes, le nettoyage des API dépréciées : tout cela va dans le bon sens. Mais la question que posent ouvertement les mainteneurs de projets comme pyca/cryptography ou curl est celle-ci : est-il encore raisonnable de bâtir sur une fondation dont les décisions d'architecture des dix dernières années ont été dictées autant par la panique post-Heartbleed que par une vision technique cohérente ?

Heartbleed est devenue une métaphore, celle d'un internet qui délègue sa sécurité à des infrastructures sous-financées, maintenues dans l'ombre, et dont personne ne mesure la fragilité tant qu'elles ne s'effondrent pas.

Un calendrier à surveiller : 4.0 n'est pas une LTS

Un point d'attention essentiel pour les responsables d'infrastructure : OpenSSL 4.0 n'est pas une version LTS. Sa maintenance court jusqu'au 14 mai 2027 seulement, alors que la branche LTS actuelle (OpenSSL 3.5) est maintenue jusqu'en avril 2030. La prochaine version sera OpenSSL 4.1 en octobre 2026, et la prochaine LTS est attendue dans environ un an.

En pratique, cela signifie que les équipes en quête de stabilité à long terme n'ont pas à se précipiter. Les candidats naturels à une migration rapide sont les opérateurs de VPN, les outils de contournement de censure ou les prestataires soumis aux échéances réglementaires post-quantiques du NIST (contractants gouvernementaux américains, institutions financières). Pour les autres, attendre la prochaine LTS est une posture tout à fait défendable.
Du côté des distributions, Fedora est en première ligne pour intégrer OpenSSL 4.0 dans sa prochaine version majeure The Fedora Project, tandis qu'Ubuntu et Debian suivront selon leurs calendriers propres, probablement pas avant respectivement Ubuntu 26.10 et Debian 14.

Sources : annonce sur GitHub, Heartbleed, AdGuard DNS, Center for Democracy and Technology, Cisco

Et vous ?

ECH contre filtrage réseau : Des opérateurs réseau et des employeurs bloquent déjà ECH pour conserver leur capacité d'inspection du trafic. Cette friction est-elle acceptable au nom de la sécurité d'entreprise, ou constitue-t-elle une atteinte illégitime à la vie privée des utilisateurs ?

Le cas pyca/cryptography : Si des projets aussi centraux que la bibliothèque cryptographique de Python migrent effectivement vers une alternative à OpenSSL (BoringSSL ? aws-lc ?), quelles conséquences pour la fragmentation de l'écosystème cryptographique open source ?

Post-quantique : urgence ou marketing ? Les attaques "harvest now, decrypt later" sont-elles un risque réel et immédiat pour la plupart des organisations, ou la mise en avant de ML-DSA et ML-KEM dans OpenSSL 4.0 relève-t-elle davantage d'un positionnement de conformité réglementaire que d'une nécessité opérationnelle urgente ?

La dette technique d'OpenSSL est-elle soluble ? Trois versions majeures après Heartbleed, la bibliothèque la plus critique de l'internet reste critiquée pour ses performances et son ergonomie de développement. Faut-il en tirer la conclusion qu'un projet de cette nature ne peut pas se réformer lui-même de l'intérieur ?

Voir aussi :

OpenSSL annonce la disponibilité de la version 3.0 et le renouvellement de la Licence Apache-2.0, avec l'utilisation du nouveau module FIPS dans les projets de développement d'applications

Heartbleed : la faille dans OpenSSL permet d'accéder à des données sécurisées par TLS/SSL