Le projet OpenSSL publique hier le premier alpha de sa prochaine version avec trois plats principaux. Le nouveau DTLS, le mécanisme GREASE et les optimisations AVX-512 pour la cryptographie post-quantique dans la bibliothèque qui crypte une bonne partie d'Internet.
Rappelons qu'OpenSSL est la bibliothèque open source qui protège les connexions de millions de serveurs, d'applications et d'appareils. Chaque fois que votre navigateur affiche le verrou, il existe de nombreuses possibilités qu'il soit derrière. Par conséquent, votre alpha est une nouveauté même si elle n’a pas encore été installée dans un endroit sérieux.
Parce que cela devrait être clair dès le début. Il s'agit d'une version de test, non adaptée à la production, et la date de la version finale 4.1 n'est même pas fixée.
Cinq mois après la version 4.0, la première alpha arrive
La version finale 4.0 est sortie le 14 avril avec une grande nouveauté : l'arrivée du HELLO chiffré sur le serveur (dit ECH), davantage de cryptographie post-quantique et un nettoyage des anciens protocoles, comme annoncé par le projet. Il s'agissait d'une version de transition avec une date d'expiration proche. Le projet le maintiendra jusqu'au 14 mai 2027, tandis que le vétéran 3.5 continue en tant que branche de support étendu (LTS).
Depuis, la maintenance ne s’est pas arrêtée. Fin août, la version 4.0.2 est arrivée avec un correctif de gravité modérée qui évite une consommation excessive de mémoire lors du traitement des enregistrements DTLS des époques futures. L'Alpha 1 de la version 4.1 s'appuie sur cette base déjà solide et ajoute de véritables nouvelles fonctionnalités.
Le changelog officiel confirme le menu. Prise en charge de DTLS 1.3 selon RFC 9147, avec son guide d'utilisation inclus. Prise en charge GREASE selon RFC 8701, activée avec l'option SSL_OP_GREASE et avec un drapeau -grease pour l'outil s_client. Et premier support des processeurs russes Elbrus 2000, en plus du retrait définitif d'Itanium et de Windows CE côté Windows.
Trois pièces méritent une explication tranquille. Allons avec eux.
DTLS 1.3, le chiffrement pour un Internet qui n'attend pas
TLS, le protocole de verrouillage, transite par TCP, ce qui garantit que chaque paquet arrive dans l'ordre. Mais il existe tout un monde qui n’utilise pas TCP. Les appels vidéo, la voix sur IP, de nombreux VPN, les jeux en ligne et les capteurs IoT parlent tous UDP, où les paquets peuvent être perdus ou arriver dans le désordre. Pour eux il existe DTLS, le jumeau de TLS adapté aux datagrammes.
Le problème est que ce jumeau était coincé dans le passé depuis des années. OpenSSL comprenait DTLS 1.0 et 1.2, mais la version 1.3, sortie en standard en avril 2022, manquait toujours. Quatre ans plus tard, l'alpha l'apporte enfin.
FreeBSD porte le logiciel ROCm d'AMD pour le HPC et l'IA sur les GPU
DTLS avec vitamines
Et ça apporte beaucoup. La poignée de main initiale entre ordinateurs sur Internet passe de deux allers-retours à un seul, la connexion est donc plus rapide. Seuls les chiffrements modernes avec authentification intégrée sont pris en charge, tout ce qui précède est conservé pour des raisons de compatibilité jusqu'à sa suppression, mais le protocole par défaut est sécurisé de par sa conception.
De plus, chaque session utilise des clés éphémères qui sont détruites une fois terminées, donc voler la clé du serveur demain ne vous permettra pas de décrypter ce qui a été enregistré aujourd'hui. Et il existe un espace natif pour la cryptographie post-quantique qui résistera aux ordinateurs quantiques du futur.
Il existe des détails plus fins pour les réseaux hostiles. Un mécanisme de cookie oblige le client à prouver son adresse avant que le serveur n'effectue aucune tâche, ce qui stoppe les attaques par déni de service si faciles sur UDP. Les messages volumineux sont fragmentés et réassemblés sans dépendre du système d'exploitation. Et les sessions peuvent être reprises avec les données du premier paquet, appelé 0-RTT, pour des latences minimales.
Sécurité et rapidité, enfin ensemble. Et pour les programmeurs, il y a un cadeau supplémentaire. L'API OpenSSL Listener sert désormais DTLS en plus de QUIC, séparant les datagrammes entrants par client de manière ordonnée. Moins de code artisanal sur chaque serveur, plus de sécurité et d'intégration dans le développement.
GRAISSE ou WD-40 sur Internet
La deuxième pièce porte le nom le plus drôle de la cryptographie récente et son nom est GREASE. Ce protocole répond à une problématique presque philosophique : TLS est conçu pour évoluer, avec des listes de capacités que le client propose et que le serveur choisit, ignorant ce qu'il ne connaît pas.
Mais certains programmes comportent des erreurs et rompent la connexion lorsqu’ils sont confrontés à des valeurs inconnues. Puisque tout fonctionne avec les clients actuels, l’erreur se propage silencieusement. Des années plus tard, lorsqu’une nouvelle fonctionnalité arrive réellement, il est impossible de la déployer, il faut se salir les mains et apporter « correctifs sur correctifs » pour y remédier.
Et il y a déjà beaucoup de tissu à découper. En février 2017, Google a activé TLS 1.3 dans Chrome 56 et des milliers d'ordinateurs derrière les proxys Blue Coat se sont retrouvés sans Internet. Les appareils intermédiaires (les proxys) n'ont pas toléré la nouvelle et ont coupé la connexion. Google a dû faire marche arrière, camouflant TLS 1.3 pour ressembler à 1.2 et négociant avec chaque fabricant. Les pires « correctifs sur correctifs » que vous puissiez imaginer et ça fait mal, car il n'a toujours pas pu être supprimé.
«Soit tu le fais bien, soit tu ne fais rien»
Cependant, la réponse à ce problème a été normalisée en janvier 2020 sous le nom de RFC 8701, œuvre de David Benjamin. La solution est connue par beaucoup comme « voyou » mais « fonctionnelle et amusante ».
Parce que? Parce que le client envoie occasionnellement des valeurs aléatoires dénuées de sens, avec le modèle 0x?A?Adans leurs listes de chiffrements, versions et extensions. Les programmes bien conçus les ignorent et passent à autre chose (les services ne diminuent pas et tout continue son chemin).
Mais si le programme est mal écrit, votre service finit par mourir et tout plante. Oui, le protocole de cryptage lui-même peut désactiver un service si celui-ci est mal programmé. Cloudflare l'a résumé avec une image parfaite : « GREASE est comme le WD-40 d'Internet ». Il semble qu’il n’y ait rien de plus amusant en informatique que de voir des services mourir parce qu’ils sont de mauvaise qualité, un plaisir coupable.
Bien sûr, OpenSSL a mis du temps à se joindre à cette ligne. La pétition était ouverte depuis 2019 et a été clôturée par une contribution externe qui suit le modèle de BoringSSL, la bibliothèque de Google. Pour le moment, cela fonctionne côté client et peut désormais être testé manuellement avec openssl s_client -grease.
Faro Santander : un point zéro pour voir comment vieillit le futur
AVX-512 au service de l'ère post-quantique
La troisième pièce s'intéresse au processeur. Les puces modernes incluent des instructions AVX-512 capables de fonctionner avec des registres géants de 512 bits. Bien utilisés, ils permettent d’effectuer quatre opérations cryptographiques là où il n’y en avait qu’une. OpenSSL en a déjà profité dans plusieurs algorithmes et la version 4.1 étend la couverture sur deux fronts.
La première est la cryptographie post-quantique. ML-DSA, la norme de signature numérique publiée par le NIST en août 2024 sur la base du schéma CRYSTALS-Dilithium, dévore les opérations de la fonction SHAKE. L'alpha publie un chemin AVX-512 qui exécute quatre SHAKE en parallèle, en plus d'accélérer les transformations mathématiques de l'algorithme dans AVX2 et d'apporter des optimisations équivalentes aux mainframes PowerPC et s390x.
Le deuxième front est plus terrestre. Le décryptage AES-CBC, toujours omniprésent dans les réseaux privés et les systèmes existants, obtient également sa part d'AVX-512.
Ce que cela signifie pour vos équipes. Chaque connexion sécurisée négocie les clés, vérifie les signatures et crypte les données, et tout cela coûte du CPU. Sur un serveur avec des milliers de connexions par seconde, rendre ces opérations moins chères se traduit par moins de latence, plus de connexions par machine et moins de facture d'électricité. Sur votre ordinateur portable, dans des poignées de main que vous ne remarquez même pas, ou bien, peut-être un peu dans la hausse de température, puisque l'AVX-512, c'est comme verser de l'essence sur un feu, il fait tout exploser et brûler.
Il est temps de jeter du lest
Comme toute version majeure, OpenSSL 4.1 laisse des cadavres. Dans cette version, les cibles de build pour Itanium sur Windows et pour Windows CE disparaissent, deux plates-formes qui appartiennent au musée des merveilles informatiques paléolithiques. Les options de configuration sont supprimées no-ecdsa et no-ecdhce qui n'a en réalité rien désactivé et n'a fait que générer de la confusion. Maintenant, vous devez utiliser no-ec se passer de la courbe elliptique, même si ce n'est pas la meilleure idée, à moins que vous ne vouliez renoncer à certains des meilleurs algorithmes de sécurité pour Internet.
Mais alors qu’il reste du lest, de nouvelles choses tombent, certaines quelque peu exotiques. Le meilleur exemple est le support initial d'Elbrus 2000, le processeur russe destiné à l'administration et à la défense. C'est curieux, car les Elbrus 2000 sont fabriqués à Taiwan (par TSMC), puisque la Russie n'a pas la capacité de générer quoi que ce soit de plus avancé que le 90 nm, une technologie vieille de 25 ans.
De plus, la version 4.1 promet la prise en charge d'IKEv2 KDF, le mécanisme de dérivation de clé pour les VPN IPsec, ainsi qu'un correctif pour vérifier les certificats DSA avec SHA-384 et SHA-512. Dans tous les cas, il faudra attendre la version finale pour installer quoi que ce soit, mais l'adresse est sans ambiguïté. Internet se corrige également.
5 outils de cybersécurité sous Linux que vous devez maîtriser