Analyse des Librairies TLS Open Source PDF

Analyse des Librairies TLS Open Source Yosri Ben Aicha Étudiant en Fise 4A-42 Janvier 2025 Chapitre 1 Introduction Dans les cadres de mon cours de cryptographie, il nous est proposé d'approfondir...

Analyse des Librairies TLS Open Source Yosri Ben Aicha Étudiant en Fise 4A-42 Janvier 2025 Chapitre 1 Introduction Dans les cadres de mon cours de cryptographie, il nous est proposé d'approfondir nos connaissances dans ce domaine à travers différents projets. Pour mon projet, j'ai opté pour les projets 6 : Implémentation de TLS en open-source. Afin de structurer mes recherches, j'ai analysé et identifié les mots clés à l'aide de ChatGpt. Ensuite, j'ai consulté divers articles et sources spécialisées pour approfondir ma compréhension les développer ce rapport. 1.1 Contexte Le Transport Layer Security (TLS) est un protocole cryptographique essentiel qui assure la sécurité des échanges de données sur Internet. Il garantit la confidentialité, l’intégrité et l’authenticité des communications entre un client et un serveur, protégeant ainsi les informations sensibles contre les interceptions et les modifications par des tiers. Après recherche, j’ai trouvé que TLS fonctionne principalement en mode client-serveur et est la version améliorée de SSL (Secure Sockets Layer) développé par Netscape pour sécuriser les échanges sur le web. Source :https://fr.wikipedia.org/wiki/Transport_Layer_ Security. De nombreuses librairies open source implémentent TLS et sont largement utilisées dans divers domaines tels que les serveurs web, les serveurs de messagerie et les appli- cations clientes. Leur adoption massive souligne l’importance de leur sécurité et de leur fiabilité. 1.2 Problématique Malgré leur popularité, les implémentations open source de TLS peuvent présenter des vulnérabilités qui compromettent la sécurité des données échangées. Ces vulnérabilités peuvent résulter de faiblesses dans la conception mathématique des protocoles cryptogra- phiques ou d’erreurs d’implémentation dans le code des librairies. Il est crucial de comprendre : — Quelles sont les librairies TLS open source les plus répandues? — Quelles vulnérabilités critiques ont été découvertes au cours des dix dernières années ? — Ces vulnérabilités sont-elles dues à des problèmes de conception mathématique ou à des erreurs d’implémentation ? 1.3 Objectifs L’objectif principal de ce rapport est de : — Faire un état de l’art des librairies TLS open source. 4  — Dresser la liste des principales vulnérabilités découvertes au cours des dix dernières années. — Analyser les causes de ces vulnérabilités pour déterminer si elles sont principale- ment d’ordre mathématique ou liées à des erreurs de code. Les objectifs secondaires incluent : — Mettre en évidence les bonnes pratiques pour renforcer la sécurité des implémen- tations TLS. — Identifier les tendances futures telles que les protocoles post-quantiques et les nouvelles versions de TLS. 1.4 Méthodologie La méthodologie adoptée pour ce rapport comprend : — Recherche documentaire : Analyse d’articles académiques, bases de données CVE, et rapports de sécurité officiels. — Analyse comparative : Évaluation des fonctionnalités et de la popularité des différentes librairies TLS. — Étude des vulnérabilités : Classification et analyse des vulnérabilités majeures en utilisant des indicateurs comme le CVSS. Après recherche, j’ai trouvé que ces méthodes permettent une compréhension appro- fondie des forces et faiblesses des différentes implémentations TLS Chapitre 2 État de l’Art des Librairies TLS Open Source 2.1 Qu’est-ce que TLS ? Le Transport Layer Security (TLS) est un protocole qui sécurise les communications sur Internet. Il fonctionne en mode client-serveur, où un client (comme un navigateur web) se connecte à un serveur (comme un site web) de manière sécurisée. TLS est la version améliorée de SSL (Secure Sockets Layer), développé par Netscape pour sécuriser les échanges sur le web https://fr.wikipedia.org/wiki/Transport_Layer_Security. Après recherche, j’ai trouvé que TLS opère principalement aux couches 4 et 5 du modèle OSI, encapsulant des protocoles comme HTTP, FTP, et SMTP pour les sécuriser https://fr.wikipedia.org/wiki/Transport_Layer_Security. 2.2 OpenSSL OpenSSL est sans doute la librairie TLS la plus connue et la plus utilisée au monde. Créée en 1998, elle est issue du projet SSLeay et offre une vaste gamme de fonctionnalités pour la mise en œuvre de la sécurité des communications, y compris le chiffrement, la génération de clés, et la gestion des certificats. — Site officiel : https://www.openssl.org — Documentation : https://www.openssl.org/docs/ — Caractéristiques principales : — Supporte une large variété d’algorithmes cryptographiques (AES, ChaCha20, RSA, ECDHE,DHE.). — Compatible avec de nombreux systèmes d’exploitation. — Offre des outils en ligne de commande pour la gestion des certificats et des clés. — Utilisations courantes : — Sécurisation des sites web via HTTPS. — Chiffrement des communications pour les applications serveur et client. — Génération et gestion des certificats SSL/TLS. — Sécurité des réseaux 5G — Sécurité des API et micro services 6  Après recherche, j’ai trouvé que OpenSSL est souvent la cible d’audits de sécurité en raison de son utilisation répandue. 2.3 LibreSSL LibreSSL est une fork d’OpenSSL, créée par l’équipe d’OpenBSD suite à la découverte de la faille Heartbleed en 2014. L’objectif principal était d’améliorer la sécurité et la maintenabilité du code source en simplifiant et en nettoyant le code hérité d’OpenSSL. — Site officiel : https://www.libressl.org — Documentation : — Caractéristiques principales : — Code source simplifié et audité pour réduire la surface d’attaque. — Retrait des fonctionnalités jugées non sécurisées ou inutiles. — Mises à jour régulières pour répondre aux vulnérabilités. — Utilisations courantes : — Systèmes d’exploitation basés sur OpenBSD. — Applications nécessitant une version d’OpenSSL plus sécurisée. LibreSSL se distingue par son engagement envers la sécurité et la simplicité. En sup- primant les composants superflus d’OpenSSL, LibreSSL offre une alternative plus sûre et plus facile à maintenir pour les développeurs soucieux de la sécurité. Après recherche, j’ai trouvé que LibreSSL est particulièrement apprécié pour sa sécurité renforcée. Souce : https://www.e2encrypted.com/posts/openssl-vs-libressl-a-comparison- of-security-and-performance/#google_vignette 2.4 BoringSSL BoringSSL est une autre fork d’OpenSSL, développée par Google pour répondre à ses besoins internes tout en améliorant la sécurité et les performances. — Site officiel : https://boringssl.googlesource.com/boringssl — Documentation : https://boringssl.googlesource.com/boringssl/ — Caractéristiques principales : — Optimisé pour les environnements de haute performance. — Simplification du code pour faciliter la maintenance. — Intégration étroite avec les produits Google tels que Chrome et Android. — Utilisations courantes : — Projets internes chez Google. Source :https://kulturegeek.fr/news-31527/boringssllopenssl- ennuis-google — Applications nécessitant une intégration étroite avec les écosystèmes Google. BoringSSL est spécialement conçu pour les besoins de Google, offrant des améliorations de performance et de sécurité adaptées aux services à grande échelle comme Chrome et Android. Après recherche, j’ai trouvé que BoringSSL est principalement utilisé en interne par Google https://boringssl.googlesource.com/boringssl. 2.5 GnuTLS GnuTLS est une librairie TLS développée par le projet GNU, mettant l’accent sur la conformité aux standards ouverts et la sécurité. — Site officiel : https://www.gnutls.org et du — Documentation : https://www.gnutls.org/documentation.html — Caractéristiques principales : — Conformité stricte aux spécifications TLS. — Support pour une large gamme de protocoles et d’algorithmes. — Intégration facile avec d’autres projets GNU. — Utilisations courantes : — Applications nécessitant une conformité rigoureuse aux standards de sécurité. — Environnements où l’interopérabilité avec d’autres outils GNU est primordiale. GnuTLS est souvent choisi pour son adhésion stricte aux standards ouverts, garantissant une compatibilité et une sécurité optimales dans les environnements GNU/Linux. Après recherche, j’ai trouvé que GnuTLS est souvent utilisé dans les projets nécessitant une conformité stricte https://www.gnutls.org. 2.6 WolfSSL WolfSSL est une librairie TLS conçue pour les environnements embarqués, offrant une solution légère et performante. — Site officiel : https://www.wolfssl.com — Documentation : https://www.wolfssl.com/documentation/ — Caractéristiques principales : — Taille réduite et faible consommation de ressources. — Support pour les microcontrôleurs et les systèmes embarqués. — Compatibilité avec les normes de sécurité industrielles. — Utilisations courantes : — Dispositifs IoT (Internet des Things). — Systèmes embarqués nécessitant une sécurité TLS efficace. — Applications mobiles et industrielles. WolfSSL est idéal pour les projets où les ressources sont limitées, offrant une implémentation optimisée de TLS sans compromettre la sécurité. Après recherche, j’ai trouvé que WolfSSL est idéal pour les applications nécessitant des ressources limitées. 2.7 mbed TLS mbed TLS (anciennement PolarSSL) est une librairie TLS orientée vers l’intégration facile dans les applications, particulièrement dans les environnements contraints.  — Site officiel : https://tls.mbed.org — Documentation : https://tls.mbed.org/documentation — Caractéristiques principales : — Facilité d’intégration avec des API simples et bien documentées. — Modularité permettant de n’inclure que les fonctionnalités nécessaires. — Support pour de multiples plateformes et langages de programmation. — Utilisations courantes : — Applications embarquées et mobiles. — Projets nécessitant une intégration rapide et flexible. — Environnements de développement nécessitant une personnalisation poussée. mbed TLS est apprécié pour sa modularité, permettant aux développeurs d’ajuster facilement les fonctionnalités en fonction des besoins spécifiques de leur projet. Après recherche, j’ai trouvé que mbed TLS est très apprécié pour sa modularité et sa facilité d’intégration https://tls.mbed.org. Chapitre 3 Vulnérabilités Connues des Librairies TLS (2015- 2025) La sécurité des librairies TLS open source est primordiale, car elles sont largement utilisées pour protéger les communications sensibles. Cependant, comme tout logiciel com- plexe, elles ne sont pas exemptes de vulnérabilités. Ce chapitre dresse un inventaire des vulnérabilités majeures et mineures découvertes au cours des dix dernières années, et analyse leurs causes. 3.1 Vulnérabilités Majeures 3.1.1 Heartbleed (CVE-2014-0160) — Date : 2014 (impactant encore la décennie 2015+) — Bibliothèque concernée : OpenSSL (version 1.0.1 à 1.0.1f) — Nature du problème : Vulnérabilité dans l’implémentation de l’extension Heartbeat (RFC 6520) permettant la divulgation de la mémoire du serveur. — Type : Bug d’implémentation (mauvaise vérification de la longueur demandée) — Impact : Permettait à un attaquant distant de récupérer des informations sensibles (clés privées, contenu mémoire du serveur), menant à une compromission potentielle du secret TLS. Heartbleed a été l’une des failles les plus graves affectant OpenSSL. Cette vulnérabilité a permis aux attaquants de lire la mémoire des serveurs vulnérables, exposant ainsi des informations sensibles telles que les clés privées et les données des utilisateurs. Après recherche, j’ai trouvé que Heartbleed a été l’une des failles les plus graves affectant OpenSSL https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160. 3.1.2 ROBOT Attack (CVE-2017-13099) — Date : 2017 — Bibliothèque concernée : OpenSSL et autres implémentations TLS utilisant RSA avec certaines configurations PKCS #1 v1.5 — Nature du problème : Réapparition de l’attaque Bleichenbacher sur le chiffrement RSA. 10  — Type : Problème de conception cryptographique (PKCS #1 v1.5) + erreurs d’implémentation. — Impact : Permettait dans certaines conditions un déchiffrement ou une signature non autorisée si le serveur ne gérait pas correctement l’erreur de padding RSA. L’attaque ROBOT exploite des failles cryptographiques et d’implémentation dans les configurations RSA de certaines librairies TLS. Elle permet aux attaquants de déchiffrer ou de signer des données de manière non autorisée, compromettant ainsi la sécurité des communications. Après recherche, j’aitrouvé que la ROBOT Attackexploite des failles cryptographiques et d’implémentation https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13099. 3.1.3 Freak Attack (CVE-2015-0204) — Date : 2015 — Bibliothèqueconcernée : OpenSSL, SecureTransport d’Apple, etc. — Nature du problème : Attaque contre l’algorithme RSA export-grade (failles de concept lié aux “export ciphers”). — Type : Problème de conception historique (les export ciphers), mais aussi d’implémentation (acceptation de ciphers trop faibles). — Impact : Forçait l’utilisation d’un chiffrement plus faible (RSA 512 bits), permet- tant une attaque de factorisation et un déchiffrement ultérieur. La Freak Attack a forcé les serveurs vulnérables à utiliser des clés RSA de faible taille, facilitant ainsi leur déchiffrement par des attaquants. Cette faille historique a mis en lumière l’importance de désactiver les configurations de chiffrement faibles. Après recherche, j’ai trouvé que la Freak Attack exploite des configurations de chiffre- ment faibles héritées https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0204 et https://freakattack.com/ 3.1.4 Logjam (CVE-2015-4000) — Date : 2015 — Bibliothèque concernée : OpenSSL, GnuTLS, NSS (Mozilla), etc. — Nature du problème : Vulnérabilité sur l’échange de clé DiffieHellman (DH) en configuration “export-grade” (512 bits). — Type : Problème de conception (protocoles d’export) + implémentation (accepta- tion des suites DH faibles). — Impact : Possibilité pour un attaquant de downgrader une connexion pour la forcer à utiliser des clés DH 512 bits, facilitant le calcul et la compromission du secret de session. Logjam permettait aux attaquants de forcer l’utilisation de clés DiffieHellman de faible taille, rendant les échanges cryptographiques vulnérables à la compromission. Cela a souligné la nécessité de renforcer les configurations DH dans les librairies TLS. Après recherche, j’ai trouvé que Logjam permettait de forcer l’utilisation de clés DiffieHellman faibles https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4000. 3.1.5 POODLE Attack (CVE-2014-3566) — Date : 2014 — Bibliothèque concernée : Implémentations de SSL 3.0 / TLS utilisant le mode CBC. — Nature du problème : Faiblesse du protocole SSL 3.0 en lui-même. — Type : Problème de conception du protocole (et usage d’un protocole obsolète). — Impact : Permettait d’exploiter un padding oracle dans SSL 3.0. A entraîné la recommandation de désactiver définitivement SSL 3.0. L’attaque POODLE exploitait les faiblesses des modes de chiffrement CBC dans SSL 3.0, permettant aux attaquants d’intercepter et de déchiffrer les communications sécurisées. Cette vulnérabilité a conduit à l’abandon complet de SSL 3.0 au profit de versions plus sécurisées de TLS. Après recherche, j’ai trouvé que POODLE exploitait les faiblesses des modes de chiffre- ment CBC dans SSL 3.0 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566. 3.2 Vulnérabilités Mineures Outre les vulnérabilités majeures, de nombreuses failles moins critiques ont été découvertes dans les librairies TLS, souvent corrigées rapidement par les développeurs. 3.2.1 CVE-2016-2107 — Bibliothèque concernée : OpenSSL — Naturedu problème : Fuite d’information via des messages de déchiffrement mal gérés. — Impact : Divulgation partielle des données chiffrées. Cette vulnérabilité a permis une fuite limitée de données sensibles en raison d’une mauvaise gestion des messages de déchiffrement, mettant en lumière l’importance d’une validation stricte des entrées. Après recherche, j’ai trouvé que cette vulnérabilité permettait une fuite limitée de don- nées sensibles https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2107. 3.2.2 CVE-2018-0732 — Bibliothèque concernée : GnuTLS — Nature du problème : Attaques par dépassement de tampon. — Impact : Exécution de code malveillant, compromission du système. L’attaque par dépassement de tampon a permis aux attaquants d’exécuter du code non autorisé, soulignant les risques liés aux erreurs de gestion de la mémoire dans les librairies TLS. Après recherche, j’ai trouvé que cette faille permettait l’exécution de code non autorisé via un dépassement de tampon https://cve.mitre.org/cgi-bin/cvename.cgi?name= CVE-2018- 0732. 3.2.3 CVE-2020-1967 — Bibliothèque concernée : mbed TLS — Nature du problème : Utilisation après libération de la mémoire. — Impact : Exécution de code arbitraire, instabilité du système. Cette vulnérabilité, due à une gestion incorrecte de la mémoire, a permis des attaques de type heap overflow, compromettant ainsi la stabilité et la sécurité des systèmes utilisant mbed TLS. Après recherche, j’ai trouvé que cette vulnérabilité était due à une gestion incorrecte de la mémoire https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1967. 3.3 Analyse des Causes Les vulnérabilités des librairies TLS peuvent être classées en deux catégories principales : les problèmes de conception mathématique et les erreurs d’implémentation. 3.3.1 Problèmes de Conception Mathématique Certaines failles résultent de faiblesses intrinsèques dans les algorithmes cryptographiques ou dans les protocoles eux-mêmes. — Algorithmes Obsolètes : Utilisation d’algorithmes de chiffrement faibles comme RC4 ou des courbes elliptiques vulnérables. — Protocoles Vulnérables : Versions obsolètes de TLS (comme TLS 1.0) présentent des failles exploitables par des attaquants modernes. — Faiblesses dans les Mécanismes de Négociation : Permettent des attaques de type downgrade ou des attaques par oracle. L’utilisation d’algorithmes obsolètes et de versions anciennes de TLS expose les librairies TLS à des attaques modernes, compromettant ainsi la sécurité globale des communi- cations. Après recherche, j’ai trouvé que les protocoles obsolètes comme TLS 1.0 sont encore utilisés, ce qui pose des risques importants https://www.ssi.gouv.fr/agence/ publication/ssltls- etat-des-lieux-etrecommandations/. 3.3.2 Erreurs d’Implémentation D’autres vulnérabilités sont dues à des erreurs de codage, des bugs ou une mauvaise gestion des ressources dans les librairies TLS. — Gestion de la Mémoire : Erreurs comme des dépassements de tampon ou des utilisations après libération. — Validation Insuffisante: Ne pas vérifier correctement les entrées ou les paramètres peut mener à des attaques par injection. — Concurrence et Synchronisation : Problèmes dans la gestion des threads ou des accès concurrents peuvent introduire des failles exploitables. Chapitre 4 Analyse des Problèmes de Conception Mathématique vs. Implémentation 4.1 Problèmes de Conception Mathématique Les problèmes de conception mathématique concernent les fondements cryptographiques sur lesquels repose le protocole TLS. Ces failles sont souvent dues à des avancées dans la cryptanalyse ou à des choix inappropriés d’algorithmes. 4.1.1 Algorithmes Cryptographiques Faibles — RC4 : Initialement largement utilisé, RC4 a été abandonné en raison de vulnérabilités permettant des attaques de type biais sur le flux de chiffrement. — MD5 et SHA-1 : Ces fonctions de hachage ont été jugées vulnérables aux collisions, compromettant l’intégrité des données. Les algorithmes comme RC4, MD5 et SHA-1 ne sont plus considérés comme sûrs en raison de leurs vulnérabilités découvertes, nécessitant leur remplacement par des alterna- tives plus robustes. Après recherche, j’ai trouvé que les algorithmes comme RC4 ne sont plus considérés comme sûrs https://www.ssi.gouv.fr/agence/publication/ssltls-etat-des-lieux-etrecomman 4.1.2 Protocoles Obsolètes — TLS 1.0 : Vulnérable aux attaques de type BEAST (Browser Exploit Against SSL/TLS) exploitant les failles dans le mode de chiffrement CBC. — TLS 1.1 : Bien qu’une amélioration par rapport à TLS 1.0, elle reste vulnérable à certaines attaques avancées. Les versions obsolètes de TLS, telles que TLS 1.0 et TLS 1.1, présentent des failles exploitables par des attaquants modernes, justifiant leur désactivation au profit de versions plus sécurisées comme TLS 1.2 et TLS 1.3. Après recherche, j’ai trouvé que TLS 1.0 et TLS 1.1 devraient être désactivés au profit de versions plus sécurisées https://www.ssi.gouv.fr/agence/publication/ssltls-etat-des-lieu 15 4.1.3 Faiblesses dans les Mécanismes de Négociation — Downgrade Attacks : Permettent à un attaquant de forcer la négociation vers une version moins sécurisée du protocole. — Bleichenbacher’s Attack : Exploite les failles dans la validation des certificats pour décrypter les messages chiffrés. Les faiblesses dans les mécanismes de négociation permettent aux attaquants de ma- nipuler les versions des protocoles utilisés, compromettant ainsi la sécurité des échanges. Après recherche, j’ai trouvé que les attaques de type downgrade restent une menace importante https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13099. 4.2 Problèmes d’Implémentation Les erreurs d’implémentation sont souvent le résultat de bugs dans le code source des librairies TLS. Elles peuvent conduire à des vulnérabilités graves, même si les principes cryptographiques sous-jacents sont solides. 4.2.1 Gestion de la Mémoire — Heartbleed : Résulte d’une mauvaise gestion des tampons de mémoire dans OpenSSL, permettant l’extraction de données sensibles. — CVE-2020-1967 : Utilisation après libération dans mbed TLS, menant à des at- taques de type heap overflow. Une mauvaise gestion de la mémoire peut entraîner des fuites d’informations sensibles et des vulnérabilités permettant l’exécution de code arbitraire, compromettant ainsi la sécurité des systèmes. Après recherche, j’ai trouvé que Heartbleed a montré à quel point une mauvaise gestion de la mémoire peut être dangereuse https://cve.mitre.org/cgi-bin/cvename.cgi? name=CVE- 2014-0160. 4.2.2 Validation des Entrées — Injection de Commandes : Si les entrées ne sont pas correctement validées, un attaquant pourrait injecter des commandes pour exécuter du code malveillant. — Buffer Overflows : Des entrées malformées peuvent provoquer des dépassements de tampon, permettant la corruption de la mémoire. La validation insuffisante des entrées ouvre la porte à diverses attaques, telles que l’injection de commandes et les dépassements de tampon, compromettant ainsi la sécurité des applications. Après recherche, j’ai trouvé que la validation insuffisante des entrées est une cause fré- quente de vulnérabilités https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0732. 4.2.3 Concurrence et Synchronisation — Race Conditions : Permettent à un attaquant de manipuler l’ordre d’exécution des opérations pour accéder à des ressources sensibles.  — Deadlocks et Starvation : Peuvent être exploités pour déni de service ou pour perturber le fonctionnement normal des applications. Les problèmes de concurrence peuvent introduire des vulnérabilités difficiles à détecter, permettant aux attaquants de manipuler les processus internes des applications pour accéder à des ressources sensibles ou perturber leur fonctionnement. Après recherche, j’ai trouvé que les problèmes de concurrence peuvent mener à des vulnérabilités difficiles à détecter https://cve.mitre.org/cgi-bin/cvename.cgi?name= CVE- 2020- 1967. 4.3 Distinction entre Conception et Implémentation Dans la plupart des cas récents, les attaques majeures proviennent davantage de la qualité de l’implémentation (erreurs de programmation, mécanismes de fallback trop per- missifs) que de problèmes de cryptographie en elle-même. Cependant, les problèmes de design cryptographique existent lorsqu’on maintient des suites de chiffrement obsolètes ou des protocoles dépassés. Les erreurs d’implémentation sont plus fréquentes que les problèmes de conception mathématique, ce qui souligne l’importance de pratiques de codage rigoureuses et de tests de sécurité approfondis dans le développement des librairies TLS. Après recherche, j’ai trouvé que les erreurs d’implémentation sont plus fréquentes que les problèmes de conception mathématique Un graphique illustrant la répartition des failles selon leur cause montrerait une pré- dominance des erreurs d’implémentation par rapport aux problèmes de conception ma- thématique. Chapitre 5 Conclusion et Perspectives 5.1 Synthèse La sécurité des implémentations TLS open source repose non seulement sur la robus tesse mathématique des algorithmes cryptographiques, mais également sur la qualité de l’implémentation et de la configuration. Au cours des dix dernières années, plusieurs failles ont démontré que même un protocole réputé sûr pouvait être compromis par des erreurs de programmation ou la persistance de protocoles obsolètes. Cette analyse met en lumière l’importance d’une approche holistique de la sécurité, englobant à la fois les aspects cryptographiques et les pratiques de développement logiciel. 5.2 Réponse à la Problématique — Problèmes Mathématiques : Moins courants, principalement liés à l’utilisation d’anciens algorithmes ou de tailles de clés trop faibles. — Problèmes d’Implémentation : Majoritaires et récurrents (dépassements de tampon, validation insuffisante, etc.). — Combinaison des Causes : Souvent, c’est la combinaison de choix de conception (supporter de vieux algorithmes) et de bugs d’implémentation qui augmente la surface d’attaque. En conclusion, les vulnérabilités dans les librairies TLS résultent principalement d’erreurs d’implémentation, souvent combinées à des choix de conception faibles. Cela souligne la nécessité d’une vigilance continue et d’une amélioration des pratiques de développement pour renforcer la sécurité des systèmes. Après recherche, j’ai trouvé que la combinaison des deux types de problèmes est particulièrement dangereuse pour la sécurité des systèmes 5.3 Perspectives — Évolution de TLS : 18  — Adoption généralisée de TLS 1.3 avec des fonctionnalités de sécurisation améliorées. https://www.cloudflare.com/fr-fr/learning/ssl/why-use-tls- 1.3/?fbclid=IwY2xjawHn4W5leHRuA2FlbQIxMAABHQYR4AMU4GFKGNQoVIBynvOi crrVuPoqHmf5fy-rfyiEw5nlu3IZv40Pjw_aem_81EzNpfVFsumBlN4NcvEWg — Standardisation progressive de la cryptographie post-quantique. — Industrialisation de la Sécurité : — Fuzzing continu (OSS-Fuzz), audits par des organismes indépendants. — Durcissement des processus de CI/CD (Tests automatisés). — Approche Multicouche : — Même un protocole sûr peut être compromis par une mauvaise configuration de l’OS ou un code applicatif vulnérable. — Importance d’une sécurisation à tous les niveaux de l’infrastructure. Pour l’avenir, l’adoption de TLS 1.3 et la cryptographie post-quantique sont des évolutions clés pour renforcer la sécurité future des communications. De plus, l’industrialisation de la sécurité via des audits réguliers et des tests automatisés contribuera à prévenir les vulnérabilités. Enfin, une approche multicouche de la sécurité garantira une protection complète à tous les niveaux de l’infrastructure. Après recherche, j’ai trouvé que l’adoption de TLS 1.3 et la cryptographie post- quantique sont des évolutions clés pour renforcer la sécurité future https://www.ssi. gouv.fr/agence/publication/ssltls-3-ans-plus-tard/ Chapitre 6 Références 1. OpenSSL. Récupéré de https://www.openssl.org https://www.mdpi.com/2220-9964/11/9/472 2. GnuTLS. Récupéré de https://www.gnutls.org 3. LibreSSL. Récupéré de https://www.libressl.org 4. BoringSSL. Récupéré de https://boringssl.googlesource.com/ boringssl 5. WolfSSL. Récupéré de https://www.wolfssl.com 6. mbed TLS. Récupéré de https://tls.mbed.org 7. MITRE. CVE-2014-0160. Récupéré de https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2014-0160 8. MITRE. CVE-2017-13099. Récupéré de https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2017-13099 9. MITRE. CVE-2015-0204. Récupéré de https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2015-0204 10. MITRE. CVE-2015-4000. Récupéré de https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2015-4000 11. MITRE.CVE-2014-3566. Récupéré de https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2014-3566 12. MITRE. CVE-2016-2107. Récupéré de https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2016-2107 13. MITRE. CVE-2018-0732. Récupéré de https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2018-0732 14. MITRE. CVE-2020-1967. Récupéré de https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2020-1967 15. OpenBSD. LibreSSL. Récupéré de https://www.libressl.org 16. Google. BoringSSL. Récupéré de https://boringssl.googlesource.com/ boringssl 17. WolfSSL. Documentation. Récupéré de https://www.wolfssl.com/documentation/ 18. ARM. mbed TLS Documentation. Récupéré de https://tls.mbed.org/ documentation 19. ANSSI. (2012). Recommandations de sécurité pour TLS. Récupéré de https://www. ssi.gouv.fr/agence/publication/ssltls-etat-des-lieux-etrecommandations/ 20  21 REMERCIMENTS Je tiens à remercier mon encadrant et tous les membres de l’équipe de recherche en sécurité pour leur soutien et leurs conseils précieux tout au long de ce projet. Je souhaite particulièrement remercier M. Sébastien Larinier pour m’avoir offert l’opportunité d’approfondir mes connaissances dans ce domaine grâce à ce projet de recherche