OpenSSL

OpenSSL est une bibliothèque logicielle destinée aux applications qui permettent de sécuriser les communications sur les réseaux informatiques contre les écoutes clandestines et d'identifier l'interlocuteur. Elle est largement utilisée par les serveurs Internet , y compris la majorité des sites Web HTTPS .

OpenSSL contient une implémentation open source des protocoles SSL et TLS . La bibliothèque principale , écrite en langage de programmation C , implémente des fonctions cryptographiques de base et fournit diverses fonctions utilitaires. Des wrappers permettant l'utilisation de la bibliothèque OpenSSL dans divers langages informatiques sont disponibles.

L'OpenSSL Software Foundation (OSF) représente le projet OpenSSL dans la plupart des domaines juridiques, notamment les accords de licence des contributeurs, la gestion des dons, etc. OpenSSL Software Services (OSS) représente également le projet OpenSSL pour les contrats de support.

OpenSSL est disponible pour la plupart des systèmes d'exploitation de type Unix (y compris Linux , macOS et BSD ), Microsoft Windows et OpenVMS .

Le projet OpenSSL a été fondé en 1998 pour fournir un ensemble gratuit d'outils de chiffrement pour le code utilisé sur Internet. Il est basé sur un fork de SSLeay par Eric Andrew Young et Tim Hudson, dont le développement a pris fin officieusement le 17 décembre 1998, lorsque Young et Hudson ont tous deux commencé à travailler pour RSA Security . Les membres fondateurs initiaux étaient Mark Cox, Ralf Engelschall, Stephen Henson, Ben Laurie et Paul Sutton.

En 2018, la numérotation des versions d'OpenSSL est passée de 1.1.1 à 3.0.0, omettant 2 comme numéro de version majeur pour éviter un conflit avec l'un des modules d'OpenSSL. La version 3.0.0 a été la première à utiliser la licence Apache .

En mai 2019 , le comité de gestion d'OpenSSL était composé de sept personnes et de dix-sept développeurs disposant d'un accès de validation (dont beaucoup font également partie du comité de gestion d'OpenSSL). Il n'y a que deux employés à temps plein (fellows) et les autres sont des bénévoles.

Le projet dispose d'un budget inférieur à 1 million de dollars par an et repose principalement sur des dons. Le développement de TLS 1.3 a été sponsorisé par Akamai .

OpenSSL prend en charge un certain nombre d'algorithmes cryptographiques différents :

Chiffres

AES , Blowfish , Camellia , ChaCha20 , Poly1305 , SEED , CAST-128 , DES , IDEA , RC2 , RC4 , RC5 , Triple DES , GOST 28147-89 , SM4

Fonctions de hachage cryptographiques

MD5 , MD4 , MD2 , SHA-1 , SHA-2 , SHA-3 , RIPEMD-160 , MDC-2 , GOST R 34.11-94 , BLAKE2 , Whirlpool , SM3

Cryptographie à clé publique

RSA , DSA , échange de clés Diffie–Hellman , courbe elliptique , X25519 , Ed25519 , X448 , Ed448 , GOST R 34.10-2001, SM2

( La confidentialité de transmission parfaite est prise en charge à l'aide de la courbe elliptique Diffie–Hellman depuis la version 1.0. )

FIPS 140 est un programme fédéral américain pour le test et la certification des modules cryptographiques. Un premier certificat FIPS 140-1 pour le FOM 1.0 d'OpenSSL a été révoqué en juillet 2006 « lorsque des questions ont été soulevées sur l'interaction du module validé avec un logiciel externe ». Le module a été re-certifié en février 2007 avant de céder la place à FIPS 140-2. OpenSSL 1.0.2 prenait en charge l'utilisation du module d'objet OpenSSL FIPS (FOM), qui a été conçu pour fournir des algorithmes approuvés par FIPS dans un environnement validé par FIPS 140-2. OpenSSL a décidé de manière controversée de classer l'architecture 1.0.2 comme « fin de vie » ou « EOL », à compter du 31 décembre 2019, malgré les objections selon lesquelles il s'agissait de la seule version d'OpenSSL actuellement disponible avec prise en charge du mode FIPS. En raison de la fin de vie, de nombreux utilisateurs n'ont pas pu déployer correctement le FOM 2.0 et ne sont plus conformes car ils n'ont pas obtenu de support étendu pour l'architecture 1.0.2, bien que le FOM lui-même soit resté validé pendant huit mois supplémentaires.

Le module d'objet FIPS 2.0 est resté validé FIPS 140-2 dans plusieurs formats jusqu'au 1er septembre 2020, date à laquelle le NIST a déconseillé l'utilisation de FIPS 186-2 pour la norme de signature numérique et a désigné tous les modules non conformes comme « historiques ». Cette désignation comprend un avertissement aux agences fédérales selon lequel elles ne doivent pas inclure le module dans de nouveaux achats. Les trois validations OpenSSL ont été incluses dans la dépréciation : le module d'objet OpenSSL FIPS (certificat n° 1747), le module d'objet OpenSSL FIPS SE (certificat n° 2398), et le module d'objet OpenSSL FIPS RE (certificat n° 2473). ​​De nombreuses validations et clones basés sur OpenSSL « en marque blanche » créés par des consultants ont également été déplacés vers la liste historique, bien que certains modules validés FIPS avec compatibilité de remplacement aient évité la dépréciation, tels que BoringCrypto de Google et CryptoComply de SafeLogic.

Le comité de gestion d'OpenSSL a annoncé un changement dans le schéma de gestion des versions.

En raison de ce changement, le numéro majeur de la prochaine version majeure aurait dû être doublé, car le module OpenSSL FIPS occupait déjà ce numéro. Par conséquent, il a été décidé de sauter le numéro de version OpenSSL 2.0 et de continuer avec OpenSSL 3.0.

OpenSSL 3.0 a restauré le mode FIPS et a subi les tests FIPS 140-2, mais avec des retards importants : l'effort a été lancé pour la première fois en 2016 avec le soutien de SafeLogic et un soutien supplémentaire d'Oracle en 2017, mais le processus a été difficile.

Le 20 octobre 2020, le fournisseur OpenSSL FIPS Provider 3.0 a été ajouté à la liste des implémentations CMVP en cours de test, ce qui reflète un engagement officiel avec un laboratoire de test pour procéder à une validation FIPS 140-2. Cela a donné lieu à une série de certifications dans les mois suivants.

OpenSSL était sous licence double, sous la licence OpenSSL et la licence SSLeay, ce qui signifie que les termes de l'une ou l'autre des licences peuvent être utilisés. La licence OpenSSL est la licence Apache 1.0 et la licence SSLeay présente certaines similitudes avec une licence BSD à 4 clauses . Comme la licence OpenSSL était la licence Apache 1.0, mais pas la licence Apache 2.0, elle exige que la phrase « ce produit inclut un logiciel développé par le projet OpenSSL pour une utilisation dans la boîte à outils OpenSSL » apparaisse dans le matériel publicitaire et dans toute redistribution (sections 3 et 6 de la licence OpenSSL). En raison de cette restriction, la licence OpenSSL et la licence Apache 1.0 sont incompatibles avec la GNU GPL . Certains développeurs de la GPL ont ajouté une exception OpenSSL à leurs licences qui autorise spécifiquement l'utilisation d'OpenSSL avec leur système. GNU Wget et climm utilisent tous deux de telles exceptions. Certains paquets (comme Deluge ) modifient explicitement la licence GPL en ajoutant une section supplémentaire au début de la licence documentant l'exception. D'autres paquets utilisent GnuTLS sous licence LGPL , Botan sous licence BSD ou NSS sous licence MPL , qui effectuent la même tâche.

OpenSSL a annoncé en août 2015 qu'il exigerait que la plupart des contributeurs signent un accord de licence de contributeur (CLA) et qu'OpenSSL serait finalement ré-licencié selon les termes de la licence Apache 2.0 . Ce processus a commencé en mars 2017, et s'est terminé en 2018.

Le 7 septembre 2021, OpenSSL 3.0.0 a été publié sous la licence Apache 2.0.

OpenSSL 0.9.6k présente un bug qui a été découvert le 4 novembre 2003. Certaines séquences ASN.1 déclenchent un grand nombre de récursions sur les machines Windows. Windows ne peut pas gérer correctement les récursions importantes, ce qui entraîne le blocage d'OpenSSL. La possibilité d'envoyer un nombre arbitrairement élevé de séquences ASN.1 peut entraîner le blocage d'OpenSSL.

Lors de la création d'une poignée de main, le client pouvait envoyer un message ClientHello au format incorrect, ce qui conduisait OpenSSL à analyser plus que la fin du message. Attribué à l'identifiant CVE - 2011-0014 par le projet CVE, cela affectait toutes les versions OpenSSL 0.9.8h à 0.9.8q et OpenSSL 1.0.0 à 1.0.0c. Étant donné que l'analyse pouvait conduire à une lecture sur une adresse mémoire incorrecte, il était possible pour l'attaquant de provoquer un déni de service . Il était également possible que certaines applications exposent le contenu des extensions OCSP analysées , ce qui permettait à un attaquant de lire le contenu de la mémoire qui venait après le ClientHello.

Lors de l'utilisation de fonctions d'entrée/sortie de base (BIO) ou de fonctions basées sur FILE pour lire des données au format DER non fiables , OpenSSL est vulnérable. Cette vulnérabilité a été découverte le 19 avril 2012 et s'est vu attribuer l'identifiant CVE CVE - 2012-2110. Bien que cela n'affecte pas directement le code SSL/TLS d'OpenSSL, toutes les applications qui utilisaient des fonctions ASN.1 (en particulier d2i_X509 et d2i_PKCS12) n'ont pas été affectées non plus.

Lors de la gestion des suites de chiffrement CBC dans SSL, TLS et DTLS, OpenSSL s'est révélé vulnérable à une attaque temporelle lors du traitement MAC. Nadhem Alfardan et Kenny Paterson ont découvert le problème et publié leurs conclusions le 5 février 2013. La vulnérabilité a été attribuée à l'identifiant CVE CVE - 2013-0169.

Le générateur de nombres pseudo-aléatoires d'OpenSSL acquiert l'entropie à l'aide de méthodes de programmation complexes. Pour empêcher l' outil d'analyse Valgrind d'émettre des avertissements associés, un responsable de la distribution Debian a appliqué un correctif à la variante Debian de la suite OpenSSL, qui a par inadvertance cassé son générateur de nombres aléatoires en limitant le nombre total de clés privées qu'il pouvait générer à 32 768. La version cassée a été incluse dans la version Debian du 17 septembre 2006 (version 0.9.8c-1), compromettant également d'autres distributions basées sur Debian, par exemple Ubuntu . Des exploits prêts à l'emploi sont facilement disponibles.

L'erreur a été signalée par Debian le 13 mai 2008. Sur la distribution Debian 4.0 (etch), ces problèmes ont été corrigés dans la version 0.9.8c-4etch3, tandis que des correctifs pour la distribution Debian 5.0 (lenny) ont été fournis dans la version 0.9.8g-9.

Les versions 1.0.1 à 1.0.1f d'OpenSSL présentent un bug de gestion de mémoire grave dans leur implémentation de l' extension TLS Heartbeat qui pourrait être utilisé pour révéler jusqu'à 64 Ko de la mémoire de l'application à chaque battement de cœur ( CVE - 2014-0160). En lisant la mémoire du serveur Web, les attaquants pourraient accéder à des données sensibles, y compris la clé privée du serveur . Cela pourrait permettre aux attaquants de décoder des communications précédemment écoutées si le protocole de chiffrement utilisé ne garantit pas une confidentialité de transmission parfaite . La connaissance de la clé privée pourrait également permettre à un attaquant de lancer une attaque de l'homme du milieu contre toute communication future. La vulnérabilité pourrait également révéler des parties non chiffrées des demandes et réponses sensibles d'autres utilisateurs, y compris les cookies de session et les mots de passe, ce qui pourrait permettre aux attaquants de détourner l'identité d'un autre utilisateur du service.

Lors de sa divulgation le 7 avril 2014, environ 17 % ou un demi-million de serveurs Web sécurisés d'Internet certifiés par des autorités de confiance étaient considérés comme vulnérables à l'attaque. Cependant, Heartbleed peut affecter à la fois le serveur et le client.

La vulnérabilité d'injection CCS ( CVE - 2014-0224) est une vulnérabilité de contournement de sécurité qui résulte d'une faiblesse dans les méthodes OpenSSL utilisées pour le matériel de cryptage.

Cette vulnérabilité peut être exploitée par le biais d'une attaque de type "man-in-the-middle", où un attaquant peut être en mesure de décrypter et de modifier le trafic en transit. Un attaquant distant non authentifié pourrait exploiter cette vulnérabilité en utilisant une poignée de main spécialement conçue pour forcer l'utilisation d'un matériel de chiffrement faible. Une exploitation réussie pourrait conduire à une condition de contournement de sécurité où un attaquant pourrait accéder à des informations potentiellement sensibles. L'attaque ne peut être effectuée qu'entre un client et un serveur vulnérables.

Les clients OpenSSL sont vulnérables dans toutes les versions d'OpenSSL antérieures aux versions 0.9.8za, 1.0.0m et 1.0.1h. Les serveurs ne sont connus comme vulnérables que dans OpenSSL 1.0.1 et 1.0.2-beta1. Il est conseillé aux utilisateurs de serveurs OpenSSL antérieurs à la version 1.0.1 de procéder à une mise à niveau par mesure de précaution.

Cette vulnérabilité ( CVE - 2015-0291) permet à quiconque de prendre un certificat, de lire son contenu et de le modifier avec précision pour exploiter la vulnérabilité, ce qui provoque le crash d'un certificat sur un client ou un serveur. Si un client se connecte à un serveur OpenSSL 1.0.2 et renégocie avec une extension d'algorithme de signature non valide, une déréférencement de pointeur nul se produit. Cela peut provoquer une attaque DoS contre le serveur.

Un chercheur en sécurité de Stanford, David Ramos, a découvert une faille privée et l'a présentée à l'équipe OpenSSL, qui a ensuite corrigé le problème.

OpenSSL a classé le bug comme un problème de haute gravité, notant que la version 1.0.2 était vulnérable.

Cette vulnérabilité ( CVE - 2016-0701) permet, dans certaines circonstances particulières, de récupérer la clé Diffie-Hellman privée du serveur OpenSSL. Un chercheur d'Adobe System Security, Antonio Sanso, a signalé cette vulnérabilité en privé.

OpenSSL a classé le bug comme un problème de haute gravité, notant que seule la version 1.0.2 était vulnérable.

En 2009, après des frustrations avec l'API OpenSSL originale, Marco Peereboom, un développeur OpenBSD à l'époque, a bifurqué l'API originale en créant Agglomerated SSL (assl), qui réutilise l'API OpenSSL en arrière-plan, mais fournit une interface externe beaucoup plus simple. Il a depuis été déconseillé à la lumière du fork LibreSSL vers 2015.

En avril 2014, à la suite de Heartbleed , les membres du projet OpenBSD ont forké OpenSSL en commençant par la branche 1.0.1g, pour créer un projet nommé LibreSSL . base de code d'OpenSSL , plus de 90 000 lignes de code C ont été supprimées du fork.

En juin 2014, Google a annoncé son propre fork d'OpenSSL baptisé BoringSSL. Google prévoit de coopérer avec les développeurs d'OpenSSL et de LibreSSL. Google a depuis développé une nouvelle bibliothèque, Tink, basée sur BoringSSL.

En septembre 2020, il a été publié en tant que bibliothèque cryptographique à usage général maintenue par l' équipe AWS Cryptography pour être utilisée dans la plateforme de cloud computing AWS. Il est basé sur le code des projets OpenSSL et BoringSSL.

Parmi les communautés de développeurs, OpenSSL est souvent cité pour avoir introduit des ruptures de compatibilité des API à chaque nouvelle version majeure, ce qui nécessite des adaptations logicielles qui ont tendance à retarder l'adoption de nouvelles versions. Ceci, combiné au fait que les versions précédentes ne sont généralement maintenues que deux ans après la sortie d'une nouvelle version majeure tend à forcer certains fournisseurs à anticiper très tôt les migrations de logiciels tout en ayant encore peu de temps pour mettre à jour vers une nouvelle version, parfois au risque de perdre une certaine compatibilité avec les logiciels existants ou de risquer des régressions.

Alors que les versions à support long terme (LTS) sont maintenues pendant 5 ans, les retards accumulés dans les délais de publication ont tendance à forcer les éditeurs de systèmes d'exploitation à rester plus longtemps sur la dernière version prise en charge, ce qui laisse moins de marge lorsque la nouvelle version est disponible. Par exemple, OpenSSL 3.0 était initialement prévu pour le quatrième trimestre 2019 et a finalement été publié 21 mois plus tard sans prolonger la fin de support prévue pour la version 1.1.1 précédemment prise en charge, et ce malgré les changements importants qui ont nécessité des adaptations aux logiciels existants.

Le délai de support réduit de la version 1.1.1 mentionné ci-dessus suscite des inquiétudes supplémentaires chez les utilisateurs dont les charges de travail sont sensibles aux performances. Quelque temps après la disponibilité générale de la version 3.0, certains utilisateurs ont commencé à signaler de sérieuses régressions de performances affectant cette version dans des environnements multithreads, beaucoup citant l'utilisation inefficace de verrous dans des opérations fréquentes de bas niveau, citant des ralentissements de 80 à 400 fois. L'équipe OpenSSL a créé un méta-problème pour essayer de centraliser les rapports de telles régressions massives de performances. Environ la moitié de ces rapporteurs indiquent l'impossibilité pour eux de mettre à niveau vers la version 3.0 à partir de versions antérieures, ajoutant aux problèmes causés par le temps de support limité restant sur la version précédente 1.1.1.

Alors que la couche de transport QUIC était en cours d'élaboration pour prendre en charge la troisième version du protocole HTTP , il a été proposé d'utiliser TLS pour assurer la sécurité, et il a été identifié que certaines adaptations aux bibliothèques TLS seraient nécessaires. De telles modifications ont été apportées à BoringSSL , qui était la bibliothèque principalement utilisée par les développeurs de QUIC à l'époque, et plus tard portées vers d'autres bibliothèques. Un portage de ce travail a été rapidement proposé à OpenSSL. Bien que certaines discussions aient commencé le même jour, elles ont rapidement calé et ont d'abord été bloquées pour des considérations de licence, puis maintenues en attente une fois ces préoccupations dissipées. Finalement, 10 mois plus tard, le comité de gestion d'OpenSSL a annoncé dans un article de blog que cet ensemble de correctifs ne serait pas adopté pour la version 3.0 par crainte que l'API ne change au fil du temps. Finalement, plus d'un an après la sortie prévue de la version 3.0 qui n'arrivait toujours pas, une équipe de volontaires d' Akamai et de Microsoft a décidé de forker le projet sous le nom de QuicTLS et de prendre en charge ces correctifs par-dessus le code OpenSSL afin de débloquer le développement de QUIC. Cette action a été généralement bien accueillie par la communauté. Finalement, après la sortie d'OpenSSL 3.0, l'ensemble de correctifs QUIC a été reconsidéré et rejeté, provoquant des dizaines voire des centaines de réactions de déception au sein de la communauté. La ​​demande d'extraction a été clôturée, tandis que les utilisateurs ressentaient le besoin d'exprimer publiquement leur déception, ou de supplier les fournisseurs de systèmes d'exploitation de prendre en charge le fork alternatif de QuicTLS, ou de rechercher des solutions alternatives. Finalement, Rich Salz, co-fondateur du fork de QuicTLS, a annoncé son ​​intérêt à voir un projet Apache forgé à partir de QuicTLS. Au 25 février 2023, il n'existe toujours pas de bibliothèque TLS compatible QUIC prise en charge à long terme disponible par défaut dans les systèmes d'exploitation sans que les utilisateurs finaux aient à la reconstruire eux-mêmes à partir des sources.