OpenSSL 4.0 enterre SSLv3 et embrasse le post-quantique : ce qui change pour vos sites web

Le 15 avril 2026, Matt Caswell a publié OpenSSL 4.0.0 au nom de la OpenSSL Foundation. Douze ans, presque jour pour jour, après Heartbleed. La symbolique n'est pas fortuite : cette version représente la refonte la plus profonde du projet depuis sa création. Elle enterre des protocoles obsolètes, chiffre enfin le SNI, et prépare le virage post-quantique. Mais elle casse aussi — beaucoup — avec l'existant.

Ce qui disparaît : SSLv3, SSLv2 Hello, et le mécanisme « engines »

OpenSSL 4.0 supprime définitivement SSLv3 (déprécié depuis 2015, désactivé par défaut depuis la 1.1.0) ainsi que le support du Client Hello SSLv2. On tourne enfin la page de deux décennies de compatibilité défensive avec des protocoles cassés.

Plus impactant pour les distributions : le mécanisme « engines », pilier historique de l'extensibilité d'OpenSSL, est entièrement retiré. Remplacé progressivement depuis la 3.0 par l'architecture des providers, il était devenu un gouffre de maintenance, notamment pour des distributions comme Fedora qui avaient déjà fait le choix de migrer. Si vous avez du code qui charge un engine tiers (HSM, carte à puce, accélérateur matériel), il est temps de vérifier que le fournisseur propose un provider équivalent.

Des ruptures d'API qui méritent de l'attention

Plusieurs changements silencieux peuvent faire tomber du code en production sans le moindre warning à la compilation :

• ASN1_STRING devient opaque : tout accès direct aux champs internes provoque des segfaults à l'exécution, alors que la compilation passe sans broncher.
• Plusieurs fonctions X.509 voient leur signature modifiée pour intégrer des qualificatifs const.
• X509_cmp_time() et X509_cmp_current_time() sont dépréciées au profit de X509_check_certificate_times().

La consigne officielle est sans ambiguïté : compilez avec -Werror=deprecated-declarations et faites tourner vos tests sous AddressSanitizer avant tout déploiement. Beaucoup d'équipes vont découvrir, à l'occasion, des hypothèses implicites sur les structures internes d'OpenSSL.

ECH : le SNI enfin chiffré (RFC 9849)

La fonctionnalité emblématique, c'est le support d'Encrypted Client Hello. Jusqu'ici, quand votre navigateur ouvrait une connexion HTTPS vers monsite.example, le nom du domaine cible (le SNI) transitait en clair dans le tout premier paquet — parfaitement observable pour un FAI, un opérateur national, ou un équipement d'inspection de trafic. ECH chiffre ce Client Hello initial et masque le SNI.

État du déploiement à début 2026 :

• Cloudflare : supporté depuis 2023 ;
• Firefox : activé par défaut depuis la version 119 ;
• Chrome : support fonctionnel ;
• Safari : option expérimentale au niveau de l'OS, pas encore d'intégration navigateur aboutie ;
• Nginx mainline 1.29.x : supporte ECH.

Côté serveur, le déploiement suppose de publier les clés publiques dans des enregistrements DNS HTTPS — une dépendance supplémentaire qui n'est pas anodine pour une organisation de taille moyenne.

Les limites réelles d'ECH

Ne vendons pas du rêve : ECH n'est vraiment utile que sur des plateformes partagées massivement, où des milliers de domaines cohabitent derrière une même IP. Sur un petit VPS perso, la corrélation IP → domaine suffit à reconstituer la cible — ECH ne protège plus grand-chose.

Le contre-feu étatique et entreprise

ECH a immédiatement suscité des ripostes :

• Russie (novembre 2024) : blocage de l'implémentation Cloudflare, qualifiée de contournement des restrictions d'accès à l'information.
• Chine et Iran : censure de l'infrastructure DNS qui distribue les enregistrements HTTPS — ce qui revient à déplacer le point de contrôle plutôt qu'à le supprimer.

C'est là la vraie fragilité d'ECH : le protocole retombe silencieusement en TLS classique avec SNI en clair si les enregistrements DNS sont indisponibles. C'est un choix de conception (éviter de casser la navigation), mais c'est aussi une porte ouverte — il suffit de bloquer le DNS HTTPS pour neutraliser ECH.

Côté entreprise, Cisco a intégré une détection « ECH Servers » dans Secure Firewall dès octobre 2025, pour surveiller les volumes de trafic vers les CDN compatibles. Bloquer totalement ECH génère toutefois des effets de bord : certains navigateurs refusent le fallback vers un SNI en clair et produisent des timeouts de deux minutes avant d'abandonner la connexion.

Post-quantique : le virage est amorcé

La version 4.0 intègre les algorithmes standardisés par le NIST pour préparer l'ère post-quantique (ML-KEM notamment). Les détails d'implémentation restent à creuser, mais le signal est posé : les équipes qui gèrent des infrastructures TLS doivent désormais inscrire la transition post-quantique à leur feuille de route 2026-2027.

Quelle stratégie de migration ?

La bascule 1.x → 3.0 avait été plus douloureuse que prévu ; la transition 3.x → 4.0 devrait être plus digeste, notamment pour les distributions déjà sorties du mécanisme « engines ». Mon conseil :

• ne pas se précipiter en production avant d'avoir audité le code dépendant d'OpenSSL ;
• compiler en mode strict et lancer une passe complète de tests avec sanitizers ;
• profiter de la migration pour nettoyer les suites cryptographiques obsolètes côté serveur.

Mon retour

OpenSSL 4.0 est la version qu'on espérait depuis Heartbleed : un nettoyage réel de la dette technique, des API plus sûres, et des avancées de fond côté chiffrement du handshake et post-quantique. Mais c'est aussi une version qui oblige à ressortir le debugger, et qui remet sur la table des sujets qu'on pensait oubliés (le choix des providers, la publication DNS…). À court terme, la friction sera palpable ; à moyen terme, c'est le genre de release qui consolide la sécurité du web pour une décennie.