OpenSSL

OpenSSL 0.9.6k présentait un bogue, découvert le 4 novembre 2003, qui provoquait un grand nombre de récursions sur les machines Windows lors de l'exécution de certaines séquences ASN.1. Windows ne pouvant gérer correctement ces récursions importantes, OpenSSL se bloquait. L'envoi d'un nombre arbitrairement élevé de séquences ASN.1 entraînait donc le plantage d'OpenSSL.

Lors de l'établissement d'une liaison, le client pouvait envoyer un message ClientHello mal formaté, ce qui entraînait l'analyse par OpenSSL d'une partie du message au-delà de sa fin. Référencée 2011-0014 par le projet CVE, cette vulnérabilité affectait toutes les versions d'OpenSSL de 0.9.8h à 0.9.8q et de 1.0.0 à 1.0.0c. L'analyse erronée pouvant conduire à la lecture d'une adresse mémoire incorrecte, un attaquant pouvait provoquer un déni de service (DoS) . De plus, certaines applications pouvaient exposer le contenu des extensions OCSP analysées , permettant ainsi à un attaquant de lire le contenu de la mémoire suivant le ClientHello.

Lors de l'utilisation des fonctions d'entrée/sortie de base (BIO) ou des fonctions basées sur des fichiers 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 a reçu l'identifiant 2012-2110 . Bien qu'elle n'affecte pas directement le code SSL/TLS d'OpenSSL, aucune application utilisant des fonctions ASN.1 (en particulier d2i_X509 et d2i_PKCS12) n'est concernée. 2013-0169 .Le générateur de nombres pseudo-aléatoires d'OpenSSL acquiert de l'entropie grâce à des méthodes de programmation complexes. Afin d'éviter que l' outil d'analyse Valgrind n'émette d'avertissements, un mainteneur de la distribution Debian a appliqué un correctif à la version Debian de la suite OpenSSL, ce qui a involontairement compromis le générateur de nombres aléatoires en limitant à 32 768 le nombre total de clés privées qu'il pouvait générer. La ​​version défectueuse 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, comme 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 les correctifs pour la distribution Debian 5.0 (lenny) ont été fournis dans la version 0.9.8g-9.

Au sein des communautés de développeurs, OpenSSL est souvent pointé du doigt pour les ruptures de compatibilité de son API qu'il introduit à chaque nouvelle version majeure , ce qui nécessite des adaptations logicielles susceptibles de retarder l'adoption des nouvelles versions . Ce phénomène, combiné au fait que les versions précédentes ne sont généralement maintenues que pendant deux ans maximum après la sortie d'une nouvelle version majeure contraint certains fournisseurs à anticiper les migrations logicielles très tôt, alors qu'il leur reste peu de temps pour effectuer la mise à jour, parfois au risque de perdre en compatibilité avec les logiciels existants ou de provoquer des régressions

Bien que les versions à support à long terme (LTS) soient maintenues pendant 5 ans , les retards cumulés dans les délais de publication tendent à contraindre les fournisseurs de systèmes d'exploitation à maintenir plus longtemps la dernière version prise en charge, réduisant ainsi la marge de manœuvre lors de la disponibilité de la nouvelle version. 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 que la fin de support prévue pour la version 1.1.1 précédemment prise en charge ne soit prolongée, et ce malgré les changements importants qui ont nécessité des adaptations des logiciels existants.

La réduction du délai de support de la version 1.1.1 mentionnée précédemment suscite des inquiétudes supplémentaires chez les utilisateurs dont les charges de travail sont sensibles aux performances. Peu après la mise à disposition générale de la version 3.0, certains utilisateurs ont commencé à signaler d'importantes régressions de performances affectant cette version dans les environnements multithread. Nombre d'entre eux pointent du doigt l'utilisation inefficace des verrous dans les opérations de bas niveau fréquentes, faisant état de ralentissements de 80 à 400 fois. L'équipe OpenSSL a créé un méta-problème afin de centraliser les signalements de ces importantes régressions de performances. Environ la moitié des utilisateurs ayant signalé ces problèmes indiquent l'impossibilité pour eux de passer à la version 3.0 depuis les versions précédentes, ce qui aggrave les difficultés causées par le temps de support limité restant pour la version 1.1.1.

Alors que la couche transport QUIC était en cours de développement pour prendre en charge la troisième version du protocole HTTP , l'utilisation de TLS pour assurer la sécurité a été proposée , et il a été constaté que des adaptations des bibliothèques TLS seraient nécessaires. Ces modifications ont été apportées à BoringSSL , alors la bibliothèque principalement utilisée par les développeurs QUIC, puis portées vers d'autres bibliothèques . Un portage de ce travail a rapidement été proposé à OpenSSL . Bien que des discussions aient débuté le jour même, elles ont rapidement été bloquées, d'abord pour des raisons de licence , puis suspendues une fois ces problèmes résolus. Finalement, dix mois plus tard, le comité de gestion d'OpenSSL a annoncé dans un article de blog que ce correctif ne serait pas adopté pour la version 3.0, craignant que l'API n'évolue. Finalement, plus d'un an après la sortie prévue de la version 3.0, qui ne voyait toujours pas le jour, une équipe de bénévoles d' Akamai et de Microsoft décida de créer une branche du projet, QuicTLS , et d'intégrer ces correctifs au code d'OpenSSL afin de débloquer le développement de QUIC. Cette initiative fut généralement bien accueillie par la communauté. Finalement, après la sortie d'OpenSSL 3.0, le projet de correctifs QUIC fut réexaminé et abandonné , provoquant une vague de déception au sein de la communauté . La demande de fusion fut fermée, tandis que les utilisateurs exprimaient publiquement leur déception , suppliaient les fournisseurs de systèmes d'exploitation de prendre en charge la branche alternative QuicTLS ou recherchaient des solutions alternatives . ​​Finalement, Rich Salz, cofondateur de la branche QuicTLS, annonça son ​​intérêt pour la création d'un projet Apache dérivé de QuicTLS. Au 25 février 2023, il n'existe toujours pas de bibliothèque TLS compatible QUIC et prise en charge à long terme disponible par défaut dans les systèmes d'exploitation sans que les utilisateurs finaux aient besoin de la reconstruire eux-mêmes à partir des sources.