OpenSSL 4.0 : la bibliothèque qui sécurise Internet fait peau neuve

OpenSSL, la bibliothèque de chiffrement open source sur laquelle repose une bonne partie des communications sécurisées du web, passe en version 4.0.

Si vous n'avez jamais installé OpenSSL volontairement, sachez qu'il est malgré tout probablement déjà là, quelque part dans votre stack — le genre de brique logicielle qu'on oublie... jusqu'au jour où ça pète.

En 2014, la faille Heartbleed avait d'ailleurs rappelé au monde entier que cette bibliothèque, maintenue à l'époque par une poignée de développeurs, sécurisait les connexions d'à peu près tout Internet.

Sept ans plus tard, Log4j, une autre brique invisible de l'écosystème (côté Java cette fois), avait rejoué le même match.

Vos requêtes sous enveloppe scellée

La nouveauté phare, c'est le support d'Encrypted Client Hello (RFC 9849), et elle s'attaque à un angle mort du HTTPS.

En effet, quand vous vous connectez à un site en HTTPS, le contenu de vos échanges est chiffré. Mais pendant la poignée de main TLS (le protocole qui met le S dans HTTPS, et je parle pas de Jul), le nom du site que vous visitez est envoyé en clair : c'est le SNI (Server Name Indication).

Votre FAI, votre employeur ou n'importe quel intermédiaire réseau peut donc voir que vous visitez lesjoiesducode.fr (incroyable ce site sérieux), même s'il ne peut pas lire ce que vous y faites.

ECH corrige ça en chiffrant cette information dès le départ : le nom du site réel est planqué dans un message chiffré, et emballé dans un message de façade qui n'expose rien de sensible. Pour un observateur sur le réseau, toutes les connexions se ressemblent.

Côté support, Nginx 1.30 (qui vient tout juste de sortir) gère déjà ECH, tout comme Chrome et Firefox — Safari, fidèle à sa réputation, traîne encore un peu.

Grand ménage de printemps

Version majeure oblige, OpenSSL 4.0 fait aussi le tri dans ses placards. SSLv3, déprécié depuis 2015 (et désactivé par défaut depuis 2016), est définitivement supprimé.

Même sort pour les Engines, l'ancien système de plugins cryptographiques remplacé par les Providers (un mécanisme plus modulaire introduit avec OpenSSL 3.0).

Si votre code utilisait encore l'un ou l'autre (sait-on jamais), c'est le moment d'ouvrir un ticket ou de mettre votre agent IA préféré en action.

La bibliothèque poursuit également sa mue post-quantique, avec de nouveaux algorithmes de signature conçus pour résister aux futurs ordinateurs quantiques.

La pilule qui passe mal

Côté sécurité, OpenSSL 4.0 coche donc toutes les cases. Mais il y a un sujet qui fâche, et il ne date pas d'hier.

En 2021, OpenSSL 3.0 a introduit un nouveau système pour passer des paramètres aux fonctions cryptographiques : OSSL_PARAM. Sur le papier, l'idée était loin d'être absurde.

Au lieu d'appeler une fonction avec ses arguments classiques bien rangés, on lui envoie un tableau de paires "clé-valeur", un peu comme un dictionnaire — c'est plus flexible, et évidemment plus extensible.

Le problème, c'est que ce changement a fait exploser les perfs (dans le mauvais sens du terme). Résultat : selon les cas d'usage, les régressions de performance allaient jusqu'à 80x sur certaines opérations cryptographiques.

Cinq ans plus tard, rien n'a changé : OSSL_PARAM reste la norme pour toutes les nouvelles API d'OpenSSL 4.0.

Le projet pyca/cryptography, qui gère le chiffrement côté Python, envisage d'ailleurs ouvertement de larguer OpenSSL, estimant que la bibliothèque est devenue trop lourde à intégrer. Non pas pour des raisons de sécurité (celle-ci s'est considérablement améliorée depuis Heartbleed), mais parce que l'expérience développeur a pris un sacré coup.

OpenSSL 4.0 sécurise mieux le web que jamais. Reste juste à voir si les devs auront encore la patience de s'en servir.