Transport Layer Security ( TLS ) est un protocole cryptographique conçu pour assurer la sécurité des communications sur un réseau informatique, tel qu'Internet . Le protocole es...
Le protocole TLS vise principalement à assurer la sécurité, notamment la confidentialité , l'intégrité et l'authenticité grâce à l'utilisation de la cryptographie , comme l'utilisation de certificats , entre deux ou plusieurs applications informatiques communicantes. Il s'exécute dans la couche de présentation et est lui-même composé de deux couches : l'enregistrement TLS et les protocoles de négociation TLS .
Le protocole de communication DTLS ( Datagram Transport Layer Security ) étroitement lié au protocole de sécurité de la couche de transport de données (Datagram Transport Layer Security) assure la sécurité des applications basées sur les datagrammes . Dans la rédaction technique, les références à « ( D ) TLS » sont souvent utilisées lorsqu'elles s'appliquent aux deux versions.
TLS est une norme proposée par l'Internet Engineering Task Force (IETF), définie pour la première fois en 1999, et la version actuelle est TLS 1.3, définie en août 2018. TLS s'appuie sur les spécifications SSL ( Secure Sockets Layer ) désormais obsolètes (1994, 1995, 1996) développées par Netscape Communications pour ajouter le protocole HTTPS à leur navigateur Web Netscape Navigator .
Les applications pouvant communiquer avec ou sans TLS (ou SSL), le client doit demander au serveur d' établir une connexion TLS. L'un des principaux moyens d'y parvenir consiste à utiliser un numéro de port différent pour les connexions TLS. Le port 80 est généralement utilisé pour le trafic HTTP non chiffré, tandis que le port 443 est le port commun utilisé pour le trafic HTTPS chiffré . Un autre mécanisme consiste à envoyer une requête STARTTLS spécifique au protocole au serveur pour basculer la connexion vers TLS, par exemple lors de l'utilisation des protocoles de messagerie et d'actualités .
Une fois que le client et le serveur ont accepté d'utiliser TLS, ils négocient une connexion avec état en utilisant une procédure de négociation (voir § TLS handshake). Les protocoles utilisent une négociation avec un chiffrement asymétrique pour établir non seulement les paramètres de chiffrement mais également une clé partagée spécifique à la session avec laquelle les communications ultérieures sont chiffrées à l'aide d'un chiffrement symétrique . Au cours de cette négociation, le client et le serveur conviennent de divers paramètres utilisés pour établir la sécurité de la connexion :
La négociation commence lorsqu'un client se connecte à un serveur compatible TLS en demandant une connexion sécurisée et que le client présente une liste de suites de chiffrement prises en charge ( chiffres et fonctions de hachage ).
À partir de cette liste, le serveur sélectionne une fonction de chiffrement et de hachage qu’il prend également en charge et informe le client de la décision.
Le serveur fournit ensuite généralement une identification sous la forme d'un certificat numérique . Le certificat contient le nom du serveur , l' autorité de certification (CA) de confiance qui garantit l'authenticité du certificat et la clé de chiffrement publique du serveur.
Le client confirme la validité du certificat avant de procéder.
Pour générer les clés de session utilisées pour la connexion sécurisée, le client doit :
crypte un nombre aléatoire ( PreMasterSecret ) avec la clé publique du serveur et envoie le résultat au serveur (que seul le serveur devrait pouvoir décrypter avec sa clé privée) ; les deux parties utilisent ensuite le nombre aléatoire pour générer une clé de session unique pour le cryptage et le décryptage ultérieurs des données pendant la session, ou
utilise l'échange de clés Diffie-Hellman (ou sa variante DH à courbe elliptique ) pour générer de manière sécurisée une clé de session aléatoire et unique pour le chiffrement et le déchiffrement qui a la propriété supplémentaire de confidentialité persistante : si la clé privée du serveur est divulguée à l'avenir, elle ne peut pas être utilisée pour déchiffrer la session en cours, même si la session est interceptée et enregistrée par un tiers.
Cela conclut la négociation et démarre la connexion sécurisée, qui est chiffrée et déchiffrée avec la clé de session jusqu'à la fermeture de la connexion. Si l'une des étapes ci-dessus échoue, la négociation TLS échoue et la connexion n'est pas créée.
TLS et SSL ne s'intègrent pas parfaitement dans une couche unique du modèle OSI ou du modèle TCP/IP . TLS s'exécute « au-dessus d'un protocole de transport fiable (par exemple, TCP) », ce qui impliquerait qu'il se situe au-dessus de la couche de transport . Il sert au chiffrement des couches supérieures, ce qui est normalement la fonction de la couche de présentation . Cependant, les applications utilisent généralement TLS comme s'il s'agissait d'une couche de transport, même si les applications utilisant TLS doivent contrôler activement le lancement des poignées de main TLS et la gestion des certificats d'authentification échangés.
Lorsqu'elles sont sécurisées par TLS, les connexions entre un client (par exemple, un navigateur Web) et un serveur (par exemple, wikipedia.org) auront toutes les propriétés suivantes :
La connexion est privée (ou confidentielle ) car un algorithme à clé symétrique est utilisé pour chiffrer les données transmises. Les clés de ce chiffrement symétrique sont générées de manière unique pour chaque connexion et sont basées sur un secret partagé négocié au début de la session. Le serveur et le client négocient les détails de l'algorithme de chiffrement et des clés cryptographiques à utiliser avant la transmission du premier octet de données (voir ci-dessous). La négociation d'un secret partagé est à la fois sécurisée (le secret négocié est inaccessible aux indiscrets et ne peut pas être obtenu, même par un attaquant qui se place au milieu de la connexion) et fiable (aucun attaquant ne peut modifier les communications pendant la négociation sans être détecté).
L'identité des parties communicantes peut être authentifiée à l'aide d'une cryptographie à clé publique . Cette authentification est obligatoire pour le serveur et facultative pour le client.
La connexion est fiable (ou intègre ) car chaque message transmis inclut une vérification de l'intégrité du message à l'aide d'un code d'authentification du message pour éviter toute perte ou altération non détectée des données pendant la transmission.
TLS prend en charge de nombreuses méthodes différentes pour échanger des clés, chiffrer des données et authentifier l'intégrité des messages. Par conséquent, la configuration sécurisée de TLS implique de nombreux paramètres configurables, et tous les choix ne fournissent pas toutes les propriétés liées à la confidentialité décrites dans la liste ci-dessus (voir les tableaux ci-dessous § Échange de clés, § Sécurité du chiffrement et § Intégrité des données).
Des tentatives ont été faites pour contourner certains aspects de la sécurité des communications que TLS cherche à fournir, et le protocole a été révisé plusieurs fois pour répondre à ces menaces de sécurité. Les développeurs de navigateurs Web ont révisé à plusieurs reprises leurs produits pour se défendre contre d'éventuelles faiblesses de sécurité après leur découverte (voir l'historique de la prise en charge TLS/SSL des navigateurs Web).
Sécurité de la couche de transport des datagrammes
Comme le protocole DTLS conserve la sémantique du transport sous-jacent, l'application ne subit pas les retards associés aux protocoles de flux. Cependant, l'application doit gérer la réorganisation des paquets , la perte de datagrammes et les données plus grandes que la taille d'un paquet réseau de datagrammes . Comme DTLS utilise UDP ou SCTP plutôt que TCP, il évite le problème de fusion TCP , lorsqu'il est utilisé pour créer un tunnel VPN.
La version originale de 2006 de DTLS version 1.0 n'était pas un document autonome. Elle a été fournie sous la forme d'une série de deltas par rapport à TLS 1.1. De même, la version de suivi de 2012 de DTLS est un delta par rapport à TLS 1.2. On lui a attribué le numéro de version de DTLS 1.2 pour correspondre à sa version TLS. Enfin, la version 2022 de DTLS 1.3 est un delta par rapport à TLS 1.3. Comme les deux versions précédentes, DTLS 1.3 est destinée à fournir des « garanties de sécurité équivalentes [à TLS 1.3] à l'exception de la protection des commandes/non-rejouabilité ».
Le protocole TLS (Transport Layer Security Protocol), ainsi que plusieurs autres plates-formes de sécurité réseau de base, ont été développés grâce à une initiative conjointe lancée en août 1986, entre la National Security Agency, le National Bureau of Standards, la Defense Communications Agency et douze sociétés de communication et d'informatique qui ont lancé un projet spécial appelé Secure Data Network System (SDNS). Le programme a été décrit en septembre 1987 lors de la 10e Conférence nationale sur la sécurité informatique dans un vaste ensemble d'articles publiés.
Ce programme de recherche innovant s'est concentré sur la conception de la prochaine génération de réseaux de communication informatique sécurisés et de spécifications de produits à mettre en œuvre pour les applications sur les réseaux Internet publics et privés. Il était destiné à compléter les nouvelles normes Internet OSI qui émergent rapidement, à la fois dans les profils GOSIP du gouvernement américain et dans le vaste effort Internet ITU-ISO JTC1 au niveau international. Connu à l'origine sous le nom de protocole SP4, il a été rebaptisé TLS et publié par la suite en 1995 sous la forme de norme internationale ITU-T X.274|ISO/IEC 10736:1995.
Netscape a développé les protocoles SSL originaux et Taher Elgamal , scientifique en chef chez Netscape Communications de 1995 à 1998, a été décrit comme le « père de SSL ». La version 1.0 de SSL n'a jamais été publiée publiquement en raison de graves failles de sécurité dans le protocole. La version 2.0, après sa sortie en février 1995, s'est rapidement avérée contenir un certain nombre de failles de sécurité et d'utilisabilité. Elle utilisait les mêmes clés cryptographiques pour l'authentification et le cryptage des messages. Elle avait une construction MAC faible qui utilisait la fonction de hachage MD5 avec un préfixe secret, la rendant vulnérable aux attaques par extension de longueur. Elle n'offrait également aucune protection pour l'ouverture de la poignée de main ou la fermeture explicite d'un message, ce qui signifiait que les attaques de l'homme du milieu pouvaient passer inaperçues. De plus, SSL 2.0 supposait un service unique et un certificat de domaine fixe, ce qui était en conflit avec la fonction largement utilisée de l'hébergement virtuel dans les serveurs Web, de sorte que la plupart des sites Web étaient effectivement empêchés d'utiliser SSL.
Ces défauts ont nécessité la refonte complète du protocole SSL version 3.0. Publié en 1996, il a été produit par Paul Kocher en collaboration avec les ingénieurs de Netscape Phil Karlton et Alan Freier, avec une implémentation de référence de Christopher Allen et Tim Dierks de Certicom. Les versions plus récentes de SSL/TLS sont basées sur SSL 3.0. Le projet de 1996 de SSL 3.0 a été publié par l'IETF en tant que document historique dans la RFC 6101.
SSL 2.0 a été déconseillé en 2011 par la RFC 6176. En 2014, SSL 3.0 s'est avéré vulnérable à l' attaque POODLE qui affecte tous les chiffrements par blocs dans SSL ; RC4 , le seul chiffrement non par blocs pris en charge par SSL 3.0, est également susceptible d'être cassé tel qu'utilisé dans SSL 3.0. SSL 3.0 a été déconseillé en juin 2015 par la RFC 7568.
TLS 1.0
TLS 1.0 a été défini pour la première fois dans la RFC 2246 en janvier 1999 en tant que mise à niveau de SSL version 3.0, et rédigé par Christopher Allen et Tim Dierks de Certicom. Comme indiqué dans la RFC, « les différences entre ce protocole et SSL 3.0 ne sont pas dramatiques, mais elles sont suffisamment importantes pour empêcher l'interopérabilité entre TLS 1.0 et SSL 3.0 ». Tim Dierks a écrit plus tard que ces changements, et le changement de nom de « SSL » en « TLS », étaient un geste pour sauver la face de Microsoft, « afin que l'IETF ne donne pas l'impression qu'elle se contente d'approuver le protocole de Netscape ».
Le PCI Council a suggéré que les organisations migrent de TLS 1.0 vers TLS 1.1 ou supérieur avant le 30 juin 2018. En octobre 2018, Apple , Google , Microsoft et Mozilla ont annoncé conjointement qu'ils rendraient obsolètes TLS 1.0 et 1.1 en mars 2020. TLS 1.0 et 1.1 ont été officiellement abandonnés dans la RFC 8996 en mars 2021.
TLS 1.1
TLS 1.1 a été défini dans la RFC 4346 en avril 2006. Il s'agit d'une mise à jour de la version 1.0 de TLS. Les différences importantes dans cette version incluent :
Prise en charge de l'enregistrement des paramètres par l'IANA .
La prise en charge des versions TLS 1.0 et 1.1 a été largement abandonnée par les sites Web vers 2020, désactivant l'accès aux versions de Firefox antérieures à 24 et aux navigateurs basés sur Chromium antérieurs à 29.
TLS 1.2
TLS 1.2 a été défini dans la RFC 5246 en août 2008. Il est basé sur la spécification TLS 1.1 antérieure. Les principales différences sont les suivantes :
La combinaison MD5 et SHA-1 dans le hachage du message final a été remplacée par SHA-256, avec une option permettant d'utiliser des algorithmes de hachage spécifiques à la suite de chiffrement. Cependant, la taille du hachage dans le message final doit toujours être d'au moins 96 bits .
La combinaison MD5 et SHA-1 dans l'élément signé numériquement a été remplacée par un hachage unique négocié lors de la négociation , qui est par défaut SHA-1.
Amélioration de la capacité du client et du serveur à spécifier les hachages et les algorithmes de signature qu'ils acceptent.
La définition des extensions TLS et les suites de chiffrement AES ont été ajoutées.
Toutes les versions de TLS ont été affinées dans la RFC 6176 en mars 2011, supprimant leur compatibilité ascendante avec SSL de sorte que les sessions TLS ne négocient jamais l'utilisation de la version 2.0 de Secure Sockets Layer (SSL). Il n'existe actuellement aucune date officielle de dépréciation de TLS 1.2. Les spécifications de TLS 1.2 ont également été redéfinies par le document de suivi des normes RFC 8446 pour le garder aussi sécurisé que possible ; il doit désormais être considéré comme un protocole de basculement, destiné uniquement à être négocié avec les clients qui ne peuvent pas communiquer via TLS 1.3 (la définition originale de TLS 1.2 de la RFC 5246 est depuis obsolète).
TLS 1.3
TLS 1.3 a été défini dans la RFC 8446 en août 2018. Il est basé sur la spécification antérieure TLS 1.2. Les principales différences par rapport à TLS 1.2 sont les suivantes :
Séparation des algorithmes d'accord de clé et d'authentification des suites de chiffrement
Suppression de la prise en charge de nombreuses fonctionnalités non sécurisées ou obsolètes, notamment la compression , la renégociation, les chiffrements non AEAD , les chiffrements nuls , l'échange de clés non PFS (parmi lesquels les échanges de clés RSA statiques et DH statiques ), les groupes DHE personnalisés , la négociation du format de point EC, le protocole Change Cipher Spec, l'heure du message Hello UNIX et le champ de longueur de l'entrée AD dans les chiffrements AEAD
Interdire la négociation SSL ou RC4 pour des raisons de rétrocompatibilité
Intégration de l'utilisation du hachage de session
Suppression de l'utilisation du numéro de version de la couche d'enregistrement et gel du numéro pour une meilleure compatibilité ascendante
Déplacement de certains détails d'algorithme liés à la sécurité d'une annexe à la spécification et relégation de ClientKeyShare dans une annexe
Ajout du chiffrement de flux ChaCha20 avec le code d'authentification de message Poly1305
Ajout des algorithmes de signature numérique Ed25519 et Ed448
Ajout des protocoles d'échange de clés x25519 et x448
Ajout de la prise en charge de l'envoi de plusieurs réponses OCSP
Cryptage de tous les messages de négociation après le ServerHello
Network Security Services (NSS), la bibliothèque de cryptographie développée par Mozilla et utilisée par son navigateur Web Firefox , a activé TLS 1.3 par défaut en février 2017. La prise en charge de TLS 1.3 a ensuite été ajoutée — mais en raison de problèmes de compatibilité pour un petit nombre d'utilisateurs, elle n'a pas été activée automatiquement — à Firefox 52.0 , qui a été publié en mars 2017. TLS 1.3 a été activé par défaut en mai 2018 avec la sortie de Firefox 60.0 .
Google Chrome a défini TLS 1.3 comme version par défaut pendant une courte période en 2017. Il l'a ensuite supprimé comme version par défaut, en raison de boîtiers intermédiaires incompatibles tels que les proxys Web Blue Coat .
L'intolérance de la nouvelle version de TLS était l'ossification du protocole ; les boîtiers intermédiaires avaient ossifié le paramètre de version du protocole. En conséquence, la version 1.3 imite l' image filaire de la version 1.2. Ce changement est survenu très tard dans le processus de conception, n'ayant été découvert que lors du déploiement du navigateur. La découverte de cette intolérance a également conduit à l'abandon de la stratégie de négociation de la version précédente, où la version la plus correspondante était choisie, en raison de niveaux d'ossification impraticables. Le « graissage » d'un point d'extension, où un participant au protocole revendique la prise en charge d'extensions inexistantes pour garantir que les extensions non reconnues mais réellement existantes soient tolérées et ainsi résister à l'ossification, a été conçu à l'origine pour TLS, mais il a depuis été adopté ailleurs.
Lors du hackathon IETF 100 , qui a eu lieu à Singapour en 2017, le groupe TLS a travaillé sur l'adaptation d'applications open source pour utiliser TLS 1.3. Le groupe TLS était composé de personnes du Japon, du Royaume-Uni et de l'île Maurice via l'équipe cyberstorm.mu. Ce travail a été poursuivi lors du hackathon IETF 101 à Londres , et du hackathon IETF 102 à Montréal.
wolfSSL a permis l'utilisation de TLS 1.3 à partir de la version 3.11.1, publiée en mai 2017. En tant que première implémentation commerciale de TLS 1.3, wolfSSL 3.11.1 prenait en charge la version 18 et prend désormais en charge la version 28, la version finale, ainsi que de nombreuses versions plus anciennes. Une série de blogs a été publiée sur la différence de performances entre TLS 1.2 et 1.3.
Dans, le projet populaire OpenSSL a publié la version 1.1.1 de sa bibliothèque, dans laquelle la prise en charge de TLS 1.3 était « la principale nouvelle fonctionnalité ».
L' Electronic Frontier Foundation a fait l'éloge de TLS 1.3 et a exprimé son inquiétude concernant le protocole de variante Enterprise Transport Security (ETS) qui désactive intentionnellement d'importantes mesures de sécurité dans TLS 1.3. Appelé à l'origine Enterprise TLS (eTLS), ETS est une norme publiée connue sous le nom de « ETSI TS103523-3 », « Middlebox Security Protocol, Part3: Enterprise Transport Security ». Il est destiné à être utilisé entièrement dans des réseaux propriétaires tels que les systèmes bancaires. ETS ne prend pas en charge la confidentialité de transmission afin de permettre aux organisations tierces connectées aux réseaux propriétaires de pouvoir utiliser leur clé privée pour surveiller le trafic réseau afin de détecter les logiciels malveillants et de faciliter la réalisation d'audits. Malgré les avantages revendiqués, l'EFF a averti que la perte de la confidentialité de transmission pourrait faciliter l'exposition des données et a déclaré qu'il existe de meilleures façons d'analyser le trafic.
Certificats numériques
Exemple de site Web avec certificat numérique
Un certificat numérique atteste de la propriété d'une clé publique par le sujet nommé du certificat et indique certaines utilisations attendues de cette clé. Cela permet à d'autres (parties utilisatrices) de s'appuyer sur des signatures ou sur des assertions faites par la clé privée qui correspond à la clé publique certifiée. Les magasins de clés et les magasins de confiance peuvent être de différents formats, tels que .pem , .crt, .pfx et .jks .
Autorités de certification
Le protocole TLS s'appuie généralement sur un ensemble d'autorités de certification tierces de confiance pour établir l'authenticité des certificats. La confiance est généralement ancrée dans une liste de certificats distribués avec un logiciel d'agent utilisateur, et peut être modifiée par la partie utilisatrice.
Selon Netcraft , qui surveille les certificats TLS actifs, l'autorité de certification (CA) leader du marché est Symantec depuis le début de son étude (ou VeriSign avant que l'unité commerciale des services d'authentification ne soit achetée par Symantec). En 2015, Symantec représentait un peu moins d'un tiers de tous les certificats et 44 % des certificats valides utilisés par le million de sites Web les plus fréquentés, selon Netcraft. En 2017, Symantec a vendu son activité TLS/SSL à DigiCert. Dans un rapport mis à jour, il a été démontré qu'IdenTrust , DigiCert et Sectigo sont les 3 principales autorités de certification en termes de parts de marché depuis mai 2019.
En raison du choix des certificats X.509 , les autorités de certification et une infrastructure à clé publique sont nécessaires pour vérifier la relation entre un certificat et son propriétaire, ainsi que pour générer, signer et administrer la validité des certificats. Bien que cela puisse être plus pratique que de vérifier les identités via un réseau de confiance , les révélations de surveillance de masse de 2013 ont fait mieux comprendre que les autorités de certification sont un point faible du point de vue de la sécurité, permettant des attaques de type « man-in-the-middle » (MITM) si l'autorité de certification coopère (ou est compromise).
Importance des certificats SSL
Cryptage : les certificats SSL chiffrent les données envoyées entre un serveur Web et le navigateur d'un utilisateur, garantissant ainsi la protection des informations sensibles tout au long de la transmission. Cette technologie de cryptage empêche les parties non autorisées d'intercepter et d'interpréter les données, les protégeant ainsi contre d'éventuels risques tels que le piratage ou les violations de données.
Authentification : Les certificats SSL offrent également une authentification, certifiant l'intégrité d'un site Web et que les visiteurs se connectent au bon serveur plutôt qu'à un imposteur malveillant. Cette méthode d'authentification aide les consommateurs à gagner la confiance en leur garantissant qu'ils ont affaire à un site Web fiable et sécurisé.
Intégrité : Un autre rôle important des certificats SSL est de garantir l'intégrité des données. SSL utilise des techniques cryptographiques pour vérifier que les données communiquées entre le serveur et le navigateur sont intactes et non modifiées pendant le transit. Cela empêche les acteurs malveillants d'interférer avec les données, garantissant ainsi leur intégrité et leur fiabilité.
Algorithmes
Échange de clés ou accord de clés
Avant qu'un client et un serveur puissent commencer à échanger des informations protégées par TLS, ils doivent échanger ou convenir en toute sécurité d'une clé de chiffrement et d'un chiffrement à utiliser lors du chiffrement des données (voir § Chiffrement). Parmi les méthodes utilisées pour l'échange/l'accord de clés figurent : les clés publiques et privées générées avec RSA (appelées TLS_RSA dans le protocole de négociation TLS), Diffie-Hellman (TLS_DH), Diffie-Hellman éphémère (TLS_DHE), Diffie-Hellman à courbe elliptique (TLS_ECDH), Diffie-Hellman éphémère à courbe elliptique (TLS_ECDHE), Diffie-Hellman anonyme (TLS_DH_anon), la clé pré-partagée (TLS_PSK) et le mot de passe distant sécurisé (TLS_SRP).
Les méthodes d'accord de clé TLS_DH_anon et TLS_ECDH_anon n'authentifient pas le serveur ou l'utilisateur et sont donc rarement utilisées car elles sont vulnérables aux attaques de type "man-in-the-middle" . Seuls TLS_DHE et TLS_ECDHE assurent la confidentialité de transmission.
Les certificats de clés publiques utilisés lors de l'échange/accord varient également en fonction de la taille des clés de chiffrement publiques/privées utilisées lors de l'échange et donc de la robustesse de la sécurité fournie. En juillet 2013, Google a annoncé qu'il n'utiliserait plus de clés publiques de 1 024 bits et qu'il passerait plutôt à des clés de 2 048 bits pour augmenter la sécurité du chiffrement TLS qu'il fournit à ses utilisateurs, car la puissance du chiffrement est directement liée à la taille de la clé .
Dans la conception d'applications, TLS est généralement implémenté sur les protocoles de la couche transport, en chiffrant toutes les données liées au protocole de protocoles tels que HTTP , FTP , SMTP , NNTP et XMPP .
L'une des principales utilisations du protocole TLS est de sécuriser le trafic Web entre un site Web et un navigateur Web codé avec le protocole HTTP. Cette utilisation du protocole TLS pour sécuriser le trafic HTTP constitue le protocole HTTPS .
Remarques
Navigateurs Web
Depuis avril 2016 , les dernières versions de tous les principaux navigateurs Web prennent en charge TLS 1.0, 1.1 et 1.2, et ces derniers sont activés par défaut. Cependant, tous les systèmes d'exploitation Microsoft pris en charge ne prennent pas en charge la dernière version d'IE. De plus, de nombreux systèmes d'exploitation Microsoft prennent actuellement en charge plusieurs versions d'IE, mais cela a changé selon la FAQ sur la politique de cycle de vie de support d'Internet Explorer de Microsoft archivée le 20/06/2023 sur la Wayback Machine , « à compter du 12 janvier 2016, seule la version la plus récente d'Internet Explorer disponible pour un système d'exploitation pris en charge bénéficiera d'un support technique et de mises à jour de sécurité ». La page répertorie ensuite la dernière version prise en charge d'IE à cette date pour chaque système d'exploitation. La prochaine date critique serait celle où un système d'exploitation atteint la fin de vie. Depuis le 15 juin 2022, Internet Explorer 11 ne prend plus en charge les éditions de Windows 10 qui suivent la politique de cycle de vie moderne de Microsoft.
Les mesures d’atténuation contre les attaques connues ne sont pas encore suffisantes :
Mesures d'atténuation contre les attaques POODLE : certains navigateurs empêchent déjà le retour à SSL 3.0 ; toutefois, cette mesure d'atténuation doit être prise en charge non seulement par les clients, mais également par les serveurs. La désactivation de SSL 3.0 lui-même, la mise en œuvre d'un « séparation d'enregistrement anti-POODLE » ou le refus des chiffrements CBC dans SSL 3.0 sont nécessaires.
Google Chrome : terminé (TLS_FALLBACK_SCSV est implémenté depuis la version 33, le repli vers SSL 3.0 est désactivé depuis la version 39, SSL 3.0 lui-même est désactivé par défaut depuis la version 40. Le support de SSL 3.0 lui-même a été abandonné depuis la version 44.)
Mozilla Firefox : complet (le support de SSL 3.0 lui-même est abandonné depuis la version 39. SSL 3.0 lui-même est désactivé par défaut et le repli vers SSL 3.0 est désactivé depuis la version 34 , TLS_FALLBACK_SCSV est implémenté depuis la version 35. Dans ESR, SSL 3.0 lui-même est désactivé par défaut et TLS_FALLBACK_SCSV est implémenté depuis ESR 31.3.0.)
Internet Explorer : partiel (uniquement dans la version 11, SSL 3.0 est désactivé par défaut depuis avril 2015. Les versions 10 et antérieures sont toujours vulnérables contre POODLE.)
Opera : complet (TLS_FALLBACK_SCSV est implémenté depuis la version 20, le "séparation d'enregistrement anti-POODLE", qui n'est efficace qu'avec l'implémentation côté client, est implémenté depuis la version 25, SSL 3.0 lui-même est désactivé par défaut depuis la version 27. Le support de SSL 3.0 lui-même sera abandonné depuis la version 31.)
Safari : complet (uniquement sur OS X 10.8 et versions ultérieures et iOS 8, les chiffrements CBC lors du retour à SSL 3.0 sont refusés, mais cela signifie qu'il utilisera RC4, ce qui n'est pas non plus recommandé. La prise en charge de SSL 3.0 elle-même est abandonnée sur OS X 10.11 et versions ultérieures et iOS 9.)
Atténuation des risques d'attaques RC4 :
Google Chrome a désactivé RC4 sauf en tant que solution de secours depuis la version 43. RC4 est désactivé depuis Chrome 48.
Firefox a désactivé RC4 sauf comme solution de secours depuis la version 36. Firefox 44 a désactivé RC4 par défaut.
Opera a désactivé RC4 sauf comme solution de secours depuis la version 30. RC4 est désactivé depuis Opera 35.
Internet Explorer pour Windows 7 / Server 2008 R2 et pour Windows 8 / Server 2012 ont défini la priorité de RC4 sur la plus basse et peuvent également désactiver RC4, sauf en tant que solution de secours via les paramètres du registre. Internet Explorer 11 Mobile 11 pour Windows Phone 8.1 désactive RC4, sauf en tant que solution de secours si aucun autre algorithme activé ne fonctionne. Edge et IE 11 désactivent complètement RC4 en août 2016.
Atténuation contre l'attaque FREAK :
Le navigateur Android inclus avec Android 4.0 et les versions antérieures est toujours vulnérable à l'attaque FREAK.
Internet Explorer 11 Mobile est toujours vulnérable à l'attaque FREAK.
Google Chrome, Internet Explorer (bureau), Safari (bureau et mobile) et Opera (mobile) ont mis en place des mesures d'atténuation FREAK.
Mozilla Firefox sur toutes les plateformes et Google Chrome sur Windows n'ont pas été affectés par FREAK.
BoringSSL , un fork d'OpenSSL pour Chrome/Chromium et Android ainsi que d'autres applications Google.
Botan , une bibliothèque cryptographique sous licence BSD écrite en C++.
Suite BSAFE Micro Edition : une implémentation multiplateforme de TLS écrite en C à l'aide d'un module cryptographique validé FIPS
BSAFE SSL-J : une bibliothèque TLS fournissant à la fois une API propriétaire et une API JSSE , utilisant un module cryptographique validé FIPS
cryptlib : une bibliothèque de cryptographie open source portable (inclut l'implémentation TLS/SSL)
Les programmeurs Delphi peuvent utiliser une bibliothèque appelée Indy qui utilise OpenSSL ou alternativement ICS qui prend désormais en charge TLS 1.3.
GnuTLS : une implémentation libre (sous licence LGPL)
Secure Transport : une implémentation de SSL et TLS utilisée dans OS X et iOS dans le cadre de leurs packages.
wolfSSL (anciennement CyaSSL) : bibliothèque SSL/TLS intégrée mettant l'accent sur la vitesse et la taille.
Un article présenté lors de la conférence ACM 2012 sur la sécurité informatique et des communications a montré que de nombreuses applications utilisaient certaines de ces bibliothèques SSL de manière incorrecte, ce qui entraînait des vulnérabilités. Selon les auteurs :
« La cause principale de la plupart de ces vulnérabilités est la conception déplorable des API des bibliothèques SSL sous-jacentes. Au lieu d'exprimer les propriétés de sécurité de haut niveau des tunnels réseau, telles que la confidentialité et l'authentification, ces API exposent les détails de bas niveau du protocole SSL aux développeurs d'applications. En conséquence, les développeurs utilisent souvent les API SSL de manière incorrecte, en interprétant et en comprenant mal leurs multiples paramètres, options, effets secondaires et valeurs de retour. »
TLS peut également être utilisé pour créer un VPN à l'aide d'un tunnel sur toute une pile réseau , comme c'est le cas avec OpenVPN et OpenConnect . De nombreux fournisseurs ont désormais associé les capacités de chiffrement et d'authentification de TLS à l'autorisation. Depuis la fin des années 1990, des progrès considérables ont également été réalisés dans la création de technologies client en dehors des navigateurs Web, afin de permettre la prise en charge des applications client/serveur. Par rapport aux technologies VPN IPsec traditionnelles , TLS présente certains avantages inhérents en termes de pare-feu et de traversée NAT , ce qui facilite son administration pour les grandes populations d'accès à distance.
TLS est également une méthode standard de protection de la signalisation des applications SIP ( Session Initiation Protocol ). TLS peut être utilisé pour fournir l'authentification et le chiffrement de la signalisation SIP associée à VoIP et à d'autres applications basées sur SIP.
Sécurité
Attaques contre TLS/SSL
Les attaques importantes contre TLS/SSL sont répertoriées ci-dessous.
En février 2015, l'IETF a publié une RFC informative résumant les différentes attaques connues contre TLS/SSL.
Attaque de renégociation
Une vulnérabilité de la procédure de renégociation a été découverte en août 2009 et peut conduire à des attaques par injection de texte en clair contre SSL 3.0 et toutes les versions actuelles de TLS. Par exemple, elle permet à un attaquant qui peut détourner une connexion https d'insérer ses propres requêtes au début de la conversation que le client a avec le serveur Web. L'attaquant ne peut pas réellement décrypter la communication client-serveur, ce qui est différent d'une attaque de l'homme du milieu classique. Une solution à court terme consiste à ce que les serveurs Web arrêtent d'autoriser la renégociation, ce qui ne nécessitera généralement pas d'autres modifications à moins que l'authentification par certificat client ne soit utilisée. Pour corriger la vulnérabilité, une extension d'indication de renégociation a été proposée pour TLS. Elle obligera le client et le serveur à inclure et à vérifier les informations sur les négociations précédentes dans toutes les négociations de renégociation. Cette extension est devenue une norme proposée et s'est vu attribuer le numéro RFC 5746. La RFC a été implémentée par plusieurs bibliothèques.
Attaques de rétrogradation :Attaque FREAK etAttaque par embâcle
Une attaque de rétrogradation de protocole (également appelée attaque de restauration de version) incite un serveur Web à négocier des connexions avec des versions précédentes de TLS (telles que SSLv2) qui ont depuis longtemps été abandonnées car jugées non sécurisées.
Des modifications antérieures aux protocoles originaux, comme False Start (adopté et activé par Google Chrome ) ou Snap Start , auraient introduit des attaques de rétrogradation du protocole TLS limitées ou permis des modifications de la liste de suites de chiffrement envoyée par le client au serveur. Ce faisant, un attaquant pourrait réussir à influencer la sélection de la suite de chiffrement dans une tentative de rétrogradation de la suite de chiffrement négociée pour utiliser soit un algorithme de chiffrement symétrique plus faible, soit un échange de clés plus faible. Un article présenté lors d'une conférence de l'ACM sur la sécurité informatique et des communications en 2012 a démontré que l'extension False Start était en danger : dans certaines circonstances, elle pourrait permettre à un attaquant de récupérer les clés de chiffrement hors ligne et d'accéder aux données chiffrées.
Les attaques de dégradation du chiffrement peuvent forcer les serveurs et les clients à négocier une connexion à l'aide de clés cryptographiquement faibles. En 2014, une attaque de type « man-in-the-middle » appelée FREAK a été découverte, affectant la pile OpenSSL , le navigateur Web Android par défaut et certains navigateurs Safari . L'attaque consistait à tromper les serveurs pour qu'ils négocient une connexion TLS à l'aide de clés de chiffrement 512 bits cryptographiquement faibles.
Logjam est une faille de sécurité découverte en mai 2015 qui exploite la possibilité d'utiliser des groupes Diffie-Hellman 512 bits « de qualité export » hérités des années 1990. Elle force les serveurs sensibles à rétrograder vers des groupes Diffie-Hellman 512 bits cryptographiquement faibles. Un attaquant peut alors déduire les clés que le client et le serveur déterminent à l'aide de l' échange de clés Diffie-Hellman .
Attaques inter-protocoles : DROWN
L' attaque DROWN est un exploit qui attaque les serveurs prenant en charge les suites de protocoles SSL/TLS contemporaines en exploitant leur prise en charge du protocole SSLv2 obsolète et non sécurisé pour exploiter une attaque sur les connexions utilisant des protocoles à jour qui seraient autrement sécurisés. DROWN exploite une vulnérabilité dans les protocoles utilisés et la configuration du serveur, plutôt qu'une erreur d'implémentation spécifique. Les détails complets de DROWN ont été annoncés en mars 2016, ainsi qu'un correctif pour l'exploit. À cette époque, plus de 81 000 des 1 million de sites Web les plus populaires figuraient parmi les sites Web protégés par TLS qui étaient vulnérables à l'attaque DROWN.
Attaque de la BÊTE
Le 23 septembre 2011, les chercheurs Thai Duong et Juliano Rizzo ont démontré une preuve de concept appelée BEAST ( Browser Exploit Against SSL/TLS ) en utilisant une applet Java pour violer les contraintes de la politique d'origine commune , pour une vulnérabilité de chaînage de blocs de chiffrement (CBC) connue de longue date dans TLS 1.0 : un attaquant observant 2 blocs de texte chiffré consécutifs C0, C1 peut tester si le bloc de texte en clair P1 est égal à x en choisissant le prochain bloc de texte en clair P2 = x ⊕ C0 ⊕ C1 ; selon l'opération CBC, C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x) , qui sera égal à C1 si x = P1 . Aucune exploitation pratique n'avait été démontrée auparavant pour cette vulnérabilité , découverte à l'origine par Phillip Rogaway en 2002. La vulnérabilité de l'attaque avait été corrigée avec TLS 1.1 en 2006, mais TLS 1.1 n'avait pas été largement adopté avant cette démonstration d'attaque.
RC4 en tant que chiffrement de flux est immunisé contre les attaques BEAST. Par conséquent, RC4 a été largement utilisé comme moyen d'atténuer les attaques BEAST côté serveur. Cependant, en 2013, les chercheurs ont découvert d'autres faiblesses dans RC4. Par la suite, l'activation de RC4 côté serveur n'a plus été recommandée.
Chrome et Firefox ne sont pas vulnérables aux attaques BEAST, cependant, Mozilla a mis à jour ses bibliothèques NSS pour atténuer les attaques de type BEAST . NSS est utilisé par Mozilla Firefox et Google Chrome pour implémenter SSL. Certains serveurs Web qui ont une implémentation défectueuse de la spécification SSL peuvent cesser de fonctionner en conséquence.
Microsoft a publié le bulletin de sécurité MS12-006 le 10 janvier 2012, qui corrigeait la vulnérabilité BEAST en modifiant la manière dont le composant Windows Secure Channel ( Schannel ) transmet les paquets réseau chiffrés depuis le serveur. Les utilisateurs d'Internet Explorer (antérieurs à la version 11) qui s'exécutent sur des versions plus anciennes de Windows ( Windows 7 , Windows 8 et Windows Server 2008 R2 ) peuvent limiter l'utilisation de TLS à 1.1 ou supérieur.
Apple a corrigé la vulnérabilité BEAST en implémentant la séparation 1/n-1 et en l'activant par défaut dans OS X Mavericks , publié le 22 octobre 2013.
Attaques CRIME et BREACH
Les auteurs de l'attaque BEAST sont également les créateurs de l' attaque CRIME ultérieure , qui peut permettre à un attaquant de récupérer le contenu des cookies Web lorsque la compression des données est utilisée avec TLS. cookies d'authentification secrets , il permet à un attaquant d'effectuer un détournement de session sur une session Web authentifiée.
Alors que l'attaque CRIME a été présentée comme une attaque générale qui pourrait fonctionner efficacement contre un grand nombre de protocoles, y compris mais sans s'y limiter à TLS et aux protocoles de couche applicative tels que SPDY ou HTTP , seuls des exploits contre TLS et SPDY ont été démontrés et largement atténués dans les navigateurs et les serveurs. L'exploit CRIME contre la compression HTTP n'a pas été atténué du tout, même si les auteurs de CRIME ont averti que cette vulnérabilité pourrait être encore plus répandue que la compression SPDY et TLS combinées. En 2013, une nouvelle instance de l'attaque CRIME contre la compression HTTP, baptisée BREACH , a été annoncée. Sur la base de l'attaque CRIME, une attaque BREACH peut extraire des jetons de connexion, des adresses e-mail ou d'autres informations sensibles du trafic Web chiffré TLS en seulement 30 secondes (selon le nombre d'octets à extraire), à condition que l'attaquant incite la victime à visiter un lien Web malveillant ou soit capable d'injecter du contenu dans des pages valides que l'utilisateur visite (ex : un réseau sans fil sous le contrôle de l'attaquant). Toutes les versions de TLS et SSL sont exposées au risque de BREACH, quel que soit l'algorithme de chiffrement ou le chiffrement utilisé. Contrairement aux instances précédentes de CRIME, contre lesquelles il est possible de se défendre avec succès en désactivant la compression TLS ou la compression d'en-tête SPDY, BREACH exploite la compression HTTP qui ne peut pas être désactivée de manière réaliste, car pratiquement tous les serveurs Web s'appuient sur elle pour améliorer les vitesses de transmission des données pour les utilisateurs. Il s'agit d'une limitation connue de TLS, car il est susceptible d'être attaqué par texte clair choisi contre les données de la couche application qu'il est censé protéger.
Certains experts ont également recommandé d'éviter le chiffrement CBC triple DES . Étant donné que les derniers chiffrements pris en charge développés pour prendre en charge tout programme utilisant la bibliothèque SSL/TLS de Windows XP comme Internet Explorer sur Windows XP sont RC4 et Triple-DES, et que RC4 est désormais obsolète (voir la discussion sur les attaques RC4 ), cela rend difficile la prise en charge de toute version de SSL pour tout programme utilisant cette bibliothèque sur XP.
Un correctif a été publié sous la forme de l'extension Encrypt-then-MAC de la spécification TLS, publiée sous la forme de RFC 7366. L'attaque Lucky Thirteen peut être atténuée dans TLS 1.2 en utilisant uniquement les chiffrements AES_GCM ; AES_CBC reste vulnérable. SSL peut protéger les e-mails, la VoIP et d'autres types de communications sur des réseaux non sécurisés en plus de son cas d'utilisation principal de transmission sécurisée de données entre un client et le serveur
Attaque de CANICHE
Le 14 octobre 2014, les chercheurs de Google ont publié une vulnérabilité dans la conception de SSL 3.0, qui rend le mode de fonctionnement CBC avec SSL 3.0 vulnérable à une attaque de type padding ( CVE - 2014-3566). Ils ont nommé cette attaque POODLE ( Padding Oracle On Downgraded Legacy Encryption ). En moyenne, les attaquants n'ont besoin que de 256 requêtes SSL 3.0 pour révéler un octet de messages chiffrés.
Bien que cette vulnérabilité n'existe que dans SSL 3.0 et que la plupart des clients et serveurs prennent en charge TLS 1.0 et les versions ultérieures, tous les principaux navigateurs rétrogradent volontairement vers SSL 3.0 si les échanges avec les versions plus récentes de TLS échouent, à moins qu'ils ne fournissent la possibilité à un utilisateur ou à un administrateur de désactiver SSL 3.0 et que l'utilisateur ou l'administrateur le fasse . Par conséquent, l'homme du milieu peut d'abord mener une attaque de restauration de version , puis exploiter cette vulnérabilité.
Le 8 décembre 2014, une variante de POODLE a été annoncée qui a un impact sur les implémentations TLS qui n'appliquent pas correctement les exigences d'octets de remplissage.
Attaques RC4
Malgré l'existence d'attaques sur RC4 qui ont brisé sa sécurité, les suites de chiffrement dans SSL et TLS qui étaient basées sur RC4 étaient toujours considérées comme sûres avant 2013 en fonction de la manière dont elles étaient utilisées dans SSL et TLS. En 2011, la suite RC4 a en fait été recommandée comme solution de contournement pour l' attaque BEAST . De nouvelles formes d'attaque divulguées en mars 2013 ont démontré de manière concluante la faisabilité de briser RC4 dans TLS, suggérant que ce n'était pas une bonne solution de contournement pour BEAST. Un scénario d'attaque a été proposé par AlFardan, Bernstein, Paterson, Poettering et Schuldt qui utilisait des biais statistiques récemment découverts dans la table de clés RC4 pour récupérer des parties du texte en clair avec un grand nombre de chiffrements TLS. Une attaque sur RC4 dans TLS et SSL qui nécessite 13 × 2 20 chiffrements pour casser RC4 a été dévoilée le 8 juillet 2013 et décrite plus tard comme « faisable » dans la présentation qui l'accompagnait lors d'un symposium sur la sécurité USENIX en août 2013. En juillet 2015, des améliorations ultérieures de l'attaque rendent de plus en plus pratique la défaite de la sécurité du TLS chiffré par RC4.
Comme de nombreux navigateurs modernes ont été conçus pour contrer les attaques BEAST (à l'exception de Safari pour Mac OS X 10.7 ou antérieur, pour iOS 6 ou antérieur et pour Windows ; voir § Navigateurs Web), RC4 n'est plus un bon choix pour TLS 1.0. Les chiffrements CBC qui ont été affectés par l'attaque BEAST dans le passé sont devenus un choix de protection plus populaire. Mozilla et Microsoft recommandent de désactiver RC4 lorsque cela est possible. La RFC 7465 interdit l'utilisation des suites de chiffrement RC4 dans toutes les versions de TLS.
Le 1er septembre 2015, Microsoft, Google et Mozilla ont annoncé que les suites de chiffrement RC4 seraient désactivées par défaut dans leurs navigateurs ( Microsoft Edge , Internet Explorer 11 sur Windows 7/8.1/10, Firefox et Chrome ) début 2016.
Attaque par troncature
Une attaque par troncature TLS (déconnexion) bloque les demandes de déconnexion du compte d'une victime afin que l'utilisateur reste connecté à un service Web sans le savoir. Lorsque la demande de déconnexion est envoyée, l'attaquant injecte un message TCP FIN non chiffré (plus de données de l'expéditeur) pour fermer la connexion. Le serveur ne reçoit donc pas la demande de déconnexion et n'est pas au courant de la fin anormale.
Publiée en juillet 2013, l'attaque amène les services Web tels que Gmail et Hotmail à afficher une page qui informe l'utilisateur qu'il s'est déconnecté avec succès, tout en s'assurant que le navigateur de l'utilisateur conserve l'autorisation avec le service, permettant à un attaquant ayant ensuite accès au navigateur d'accéder et de prendre le contrôle du compte connecté de l'utilisateur. L'attaque ne repose pas sur l'installation de logiciels malveillants sur l'ordinateur de la victime ; les attaquants doivent simplement se placer entre la victime et le serveur Web (par exemple, en configurant un point d'accès sans fil malveillant). Cette vulnérabilité nécessite également l'accès à l'ordinateur de la victime. Une autre possibilité est que lors de l'utilisation du FTP, la connexion de données peut avoir un faux FIN dans le flux de données, et si les règles du protocole pour l'échange d'alertes close_notify ne sont pas respectées, un fichier peut être tronqué.
Attaque en texte clair contre DTLS
En février 2013, deux chercheurs de Royal Holloway, Université de Londres, ont découvert une attaque temporelle qui leur a permis de récupérer (des parties du) texte en clair à partir d'une connexion DTLS en utilisant l'implémentation OpenSSL ou GnuTLS de DTLS lorsque le mode de cryptage Cipher Block Chaining était utilisé.
Attaque impie du PAC
Cette attaque, découverte à la mi-2016, exploite les faiblesses du protocole WPAD (Web Proxy Autodiscovery Protocol ) pour exposer l'URL qu'un utilisateur Web tente d'atteindre via un lien Web compatible TLS. La divulgation d'une URL peut violer la confidentialité d'un utilisateur, non seulement en raison du site Web consulté, mais également parce que les URL sont parfois utilisées pour authentifier les utilisateurs. Les services de partage de documents, tels que ceux proposés par Google et Dropbox, fonctionnent également en envoyant à un utilisateur un jeton de sécurité inclus dans l'URL. Un attaquant qui obtient de telles URL peut être en mesure d'obtenir un accès complet au compte ou aux données d'une victime.
L'exploit fonctionne contre presque tous les navigateurs et systèmes d'exploitation.
Attaque Sweet32
L'attaque Sweet32 brise tous les chiffrements par blocs 64 bits utilisés en mode CBC comme dans TLS en exploitant une attaque d'anniversaire et soit une attaque de l'homme du milieu, soit l'injection d'un code JavaScript malveillant dans une page Web. Le but de l'attaque de l'homme du milieu ou de l'injection JavaScript est de permettre à l'attaquant de capturer suffisamment de trafic pour lancer une attaque d'anniversaire.
Erreurs d'implémentation :Bug de saignement de cœur,Attaque BERserk, bug Cloudflare
Le bug Heartbleed est une vulnérabilité grave propre à l'implémentation de SSL/TLS dans la bibliothèque de logiciels cryptographiques OpenSSL , qui affecte les versions 1.0.1 à 1.0.1f. Cette faiblesse, signalée en avril 2014, permet aux attaquants de voler des clés privées de serveurs qui devraient normalement être protégés. Le bug Heartbleed permet à n'importe qui sur Internet de lire la mémoire des systèmes protégés par les versions vulnérables du logiciel OpenSSL. Cela compromet les clés privées secrètes associées aux certificats publics utilisés pour identifier les fournisseurs de services et pour chiffrer le trafic, les noms et mots de passe des utilisateurs et le contenu réel. Cela permet aux attaquants d'écouter les communications, de voler des données directement auprès des services et des utilisateurs et d'usurper l'identité des services et des utilisateurs. La vulnérabilité est causée par un bug de dépassement de mémoire tampon dans le logiciel OpenSSL, plutôt que par un défaut dans la spécification du protocole SSL ou TLS.
En septembre 2014, une variante de la vulnérabilité de falsification de signature RSA PKCS#1 v1.5 de Daniel Bleichenbacher a été annoncée par Intel Security Advanced Threat Research. Cette attaque, baptisée BERserk, résulte d'un décodage incomplet de la longueur ASN.1 des signatures de clés publiques dans certaines implémentations SSL et permet une attaque de type « man-in-the-middle » en falsifiant une signature de clé publique.
En février 2015, après que les médias ont signalé la préinstallation cachée du logiciel publicitaire Superfish sur certains ordinateurs portables Lenovo, un chercheur a découvert qu'un certificat racine de confiance sur les machines Lenovo concernées n'était pas sécurisé, car les clés pouvaient facilement être consultées en utilisant le nom de l'entreprise, Komodia, comme phrase de passe. La bibliothèque Komodia a été conçue pour intercepter le trafic TLS/SSL côté client à des fins de contrôle parental et de surveillance, mais elle a également été utilisée dans de nombreux programmes publicitaires, dont Superfish, qui étaient souvent installés subrepticement à l'insu de l'utilisateur de l'ordinateur. À leur tour, ces programmes potentiellement indésirables installaient le certificat racine corrompu, permettant aux attaquants de contrôler complètement le trafic Web et de confirmer l'authenticité des faux sites Web.
En mai 2016, il a été signalé que des dizaines de sites Web danois protégés par HTTPS appartenant à Visa Inc. étaient vulnérables à des attaques permettant aux pirates d'injecter du code malveillant et du contenu falsifié dans les navigateurs des visiteurs. Les attaques ont fonctionné parce que l'implémentation TLS utilisée sur les serveurs affectés a réutilisé de manière incorrecte des nombres aléatoires ( nonces ) qui sont destinés à être utilisés une seule fois, garantissant que chaque négociation TLS est unique.
En février 2017, une erreur d'implémentation causée par un seul caractère mal orthographié dans le code utilisé pour analyser le code HTML a créé une erreur de dépassement de mémoire tampon sur les serveurs Cloudflare . Similaire dans ses effets au bug Heartbleed découvert en 2014, cette erreur de dépassement, connue sous le nom de Cloudbleed , a permis à des tiers non autorisés de lire des données dans la mémoire des programmes exécutés sur les serveurs, des données qui auraient dû être protégées par TLS.
Enquête sur les sites web vulnérables aux attaques
En juillet 2021 , le Trustworthy Internet Movement a estimé le ratio de sites Web vulnérables aux attaques TLS.
Confidentialité de transmission
La confidentialité de transmission est une propriété des systèmes cryptographiques qui garantit qu'une clé de session dérivée d'un ensemble de clés publiques et privées ne sera pas compromise si l'une des clés privées est compromise à l'avenir. Sans confidentialité de transmission, si la clé privée du serveur est compromise, non seulement toutes les futures sessions chiffrées TLS utilisant ce certificat de serveur seront compromises, mais également toutes les sessions passées qui l'ont également utilisé (à condition que ces sessions passées aient été interceptées et stockées au moment de la transmission). Une implémentation de TLS peut fournir une confidentialité de transmission en exigeant l'utilisation d'un échange de clés Diffie-Hellman éphémère pour établir des clés de session, et certaines implémentations TLS notables le font exclusivement : par exemple, Gmail et d'autres services HTTPS de Google qui utilisent OpenSSL . Cependant, de nombreux clients et serveurs prenant en charge TLS (y compris les navigateurs et les serveurs Web) ne sont pas configurés pour implémenter de telles restrictions. En pratique, à moins qu'un service Web n'utilise l'échange de clés Diffie-Hellman pour mettre en œuvre la confidentialité de transmission, tout le trafic Web chiffré vers et depuis ce service peut être déchiffré par un tiers s'il obtient la clé principale (privée) du serveur ; par exemple, au moyen d'une ordonnance du tribunal.
Même lorsque l'échange de clés Diffie-Hellman est implémenté, les mécanismes de gestion de session côté serveur peuvent avoir un impact sur la confidentialité de transmission. L'utilisation de tickets de session TLS (une extension TLS) entraîne la protection de la session par AES128-CBC-SHA256 quels que soient les autres paramètres TLS négociés, y compris les suites de chiffrement de confidentialité de transmission, et les clés de ticket de session TLS à longue durée de vie contrecarrent la tentative de mise en œuvre de la confidentialité de transmission. Une recherche de l'Université de Stanford en 2014 a également révélé que sur 473 802 serveurs TLS étudiés, 82,9 % des serveurs déployant l'échange de clés Diffie-Hellman éphémère (DHE) pour prendre en charge la confidentialité de transmission utilisaient des paramètres Diffie-Hellman faibles. Ces choix de paramètres faibles pourraient potentiellement compromettre l'efficacité de la confidentialité de transmission que les serveurs cherchaient à fournir.
Depuis fin 2011, Google fournit par défaut la confidentialité de transmission avec TLS aux utilisateurs de son service Gmail , ainsi que de Google Docs et de la recherche chiffrée, entre autres services. Depuis novembre 2013, Twitter fournit la confidentialité de transmission avec TLS aux utilisateurs de son service. En août 2019 , environ 80 % des sites Web compatibles TLS sont configurés pour utiliser des suites de chiffrement qui fournissent la confidentialité de transmission à la plupart des navigateurs Web.
Interception TLS
L'interception TLS (ou HTTPS si elle s'applique particulièrement à ce protocole) est la pratique consistant à intercepter un flux de données chiffré afin de le déchiffrer, de le lire et éventuellement de le manipuler, puis de le rechiffrer et de renvoyer les données. Cela se fait par le biais d'un « proxy transparent » : le logiciel d'interception met fin à la connexion TLS entrante, inspecte le texte en clair HTTP, puis crée une nouvelle connexion TLS vers la destination.
L'interception TLS/HTTPS est utilisée comme mesure de sécurité des informations par les opérateurs de réseau afin de pouvoir détecter et protéger contre l'intrusion de contenus malveillants dans le réseau, tels que les virus informatiques et autres logiciels malveillants . Un tel contenu pourrait autrement ne pas être détecté tant qu'il est protégé par cryptage, ce qui est de plus en plus le cas en raison de l'utilisation systématique de HTTPS et d'autres protocoles sécurisés.
L'interception TLS/HTTPS présente un inconvénient majeur : elle introduit de nouveaux risques de sécurité. L'une de ses limites notables est qu'elle fournit un point où le trafic réseau est disponible sans chiffrement, ce qui incite les attaquants à attaquer ce point en particulier afin d'accéder à un contenu par ailleurs sécurisé. L'interception permet également à l'opérateur réseau, ou aux personnes qui accèdent à son système d'interception, de lancer des attaques de type « man-in-the-middle » contre les utilisateurs du réseau. Une étude de 2017 a révélé que « l'interception HTTPS est devenue étonnamment répandue et que les produits d'interception en tant que catégorie ont un impact extrêmement négatif sur la sécurité des connexions ».
Détails du protocole
Le protocole TLS échange des enregistrements , qui encapsulent les données à échanger dans un format spécifique (voir ci-dessous). Chaque enregistrement peut être compressé, complété, complété par un code d'authentification de message (MAC) ou chiffré, selon l'état de la connexion. Chaque enregistrement possède un champ de type de contenu qui désigne le type de données encapsulées, un champ de longueur et un champ de version TLS. Les données encapsulées peuvent être des messages de contrôle ou de procédure du TLS lui-même, ou simplement les données d'application devant être transférées par TLS. Les spécifications (suite de chiffrement, clés, etc.) requises pour échanger des données d'application par TLS sont convenues lors de la « négociation TLS » entre le client demandant les données et le serveur répondant aux demandes. Le protocole définit donc à la fois la structure des charges utiles transférées dans TLS et la procédure d'établissement et de surveillance du transfert.
Poignée de main TLS
Illustration simplifiée de la négociation TLS 1.2 complète avec informations de synchronisation
Lorsque la connexion démarre, l'enregistrement encapsule un protocole de « contrôle » : le protocole de messagerie de poignée de main ( type de contenu 22). Ce protocole est utilisé pour échanger toutes les informations requises par les deux parties pour l'échange des données d'application réelles par TLS. Il définit le format des messages et l'ordre de leur échange. Ceux-ci peuvent varier en fonction des exigences du client et du serveur. Il existe plusieurs procédures possibles pour établir la connexion. Cet échange initial aboutit à une connexion TLS réussie (les deux parties sont prêtes à transférer les données d'application avec TLS) ou à un message d'alerte (comme spécifié ci-dessous).
Poignée de main TLS de base
Voici un exemple de connexion typique, illustrant une négociation où le serveur (mais pas le client) est authentifié par son certificat :
Phase de négociation :
Un client envoie un message ClientHello spécifiant la version la plus élevée du protocole TLS qu'il prend en charge, un nombre aléatoire, une liste de suites de chiffrement suggérées et des méthodes de compression suggérées. Si le client tente d'effectuer une reprise de négociation, il peut envoyer un ID de session . Si le client peut utiliser la négociation de protocole de couche application , il peut inclure une liste de protocoles d'application pris en charge , tels que HTTP/2 .
Le serveur répond avec un message ServerHello contenant la version du protocole choisie, un nombre aléatoire, une suite de chiffrement et une méthode de compression parmi les choix proposés par le client. Pour confirmer ou autoriser la reprise des échanges, le serveur peut envoyer un ID de session . La version du protocole choisie doit être la plus élevée prise en charge par le client et le serveur. Par exemple, si le client prend en charge la version 1.1 de TLS et que le serveur prend en charge la version 1.2, la version 1.1 doit être sélectionnée ; la version 1.2 ne doit pas être sélectionnée.
Le serveur envoie son message de certificat (selon la suite de chiffrement sélectionnée, celui-ci peut être omis par le serveur).
Le serveur envoie son message ServerKeyExchange (selon la suite de chiffrement sélectionnée, celui-ci peut être omis par le serveur). Ce message est envoyé pour toutes les suites de chiffrement DHE , ECDHE et DH_anon.
Le serveur envoie un message ServerHelloDone , indiquant qu'il a terminé la négociation de la poignée de main.
Le client répond avec un message ClientKeyExchange , qui peut contenir un PreMasterSecret , une clé publique ou rien du tout. (Encore une fois, cela dépend du chiffrement sélectionné.) Ce PreMasterSecret est chiffré à l'aide de la clé publique du certificat du serveur.
Le client et le serveur utilisent ensuite les nombres aléatoires et PreMasterSecret pour calculer un secret commun, appelé « secret maître ». Toutes les autres données clés ( clés de session telles que IV , clé de chiffrement symétrique , clé MAC pseudo-aléatoire soigneusement conçue .
Le client envoie maintenant un enregistrement ChangeCipherSpec , indiquant essentiellement au serveur : « Tout ce que je vous dis à partir de maintenant sera authentifié (et chiffré si des paramètres de chiffrement étaient présents dans le certificat du serveur). » Le ChangeCipherSpec est lui-même un protocole de niveau enregistrement avec un type de contenu de 20.
Le client envoie un message terminé authentifié et chiffré , contenant un hachage et un MAC sur les messages de négociation précédents.
Le serveur va tenter de déchiffrer le message terminé du client et de vérifier le hachage et l'adresse MAC. Si le déchiffrement ou la vérification échoue, la négociation est considérée comme ayant échoué et la connexion doit être interrompue.
Enfin, le serveur envoie un ChangeCipherSpec , indiquant au client : « Tout ce que je vous dis à partir de maintenant sera authentifié (et chiffré, si le chiffrement a été négocié) ».
Le serveur envoie son message Terminé authentifié et crypté.
Le client exécute la même procédure de décryptage et de vérification que le serveur à l’étape précédente.
Phase d'application : à ce stade, le « handshake » est terminé et le protocole d'application est activé, avec un type de contenu de 23. Les messages d'application échangés entre le client et le serveur seront également authentifiés et éventuellement chiffrés exactement comme dans leur message terminé . Sinon, le type de contenu renverra 25 et le client ne s'authentifiera pas.
Poignée de main TLS authentifiée par le client
L' exemple complet suivant montre un client authentifié (en plus du serveur comme dans l'exemple ci-dessus ; voir authentification mutuelle ) via TLS à l'aide de certificats échangés entre les deux homologues.
Phase de négociation :
Un client envoie un message ClientHello spécifiant la version la plus élevée du protocole TLS qu'il prend en charge, un nombre aléatoire, une liste de suites de chiffrement suggérées et des méthodes de compression.
Le serveur répond avec un message ServerHello contenant la version du protocole choisi, un nombre aléatoire, une suite de chiffrement et une méthode de compression parmi les choix proposés par le client. Le serveur peut également envoyer un identifiant de session dans le cadre du message pour effectuer une reprise de la négociation.
Le serveur envoie son message de certificat (selon la suite de chiffrement sélectionnée, celui-ci peut être omis par le serveur).
Le serveur envoie son message ServerKeyExchange (selon la suite de chiffrement sélectionnée, celui-ci peut être omis par le serveur). Ce message est envoyé pour toutes les suites de chiffrement DHE, ECDHE et DH_anon. [1]
Le serveur envoie un message CertificateRequest pour demander un certificat au client.
Le serveur envoie un message ServerHelloDone , indiquant qu'il a terminé la négociation de la poignée de main.
Le client répond avec un message de certificat , qui contient le certificat du client, mais pas sa clé privée.
Le client envoie un message ClientKeyExchange , qui peut contenir un PreMasterSecret , une clé publique ou rien du tout. (Encore une fois, cela dépend du chiffrement sélectionné.) Ce PreMasterSecret est chiffré à l'aide de la clé publique du certificat du serveur.
Le client envoie un message CertificateVerify , qui est une signature sur les messages de négociation précédents à l'aide de la clé privée du certificat du client. Cette signature peut être vérifiée à l'aide de la clé publique du certificat du client. Cela permet au serveur de savoir que le client a accès à la clé privée du certificat et qu'il est donc propriétaire du certificat.
Le client et le serveur utilisent ensuite les nombres aléatoires et PreMasterSecret pour calculer un secret commun, appelé « secret maître ». Toutes les autres données clés (« clés de session ») de cette connexion sont dérivées de ce secret maître (et des valeurs aléatoires générées par le client et le serveur), qui est transmis via une fonction pseudo-aléatoire soigneusement conçue.
Le client envoie maintenant un enregistrement ChangeCipherSpec , indiquant essentiellement au serveur : « Tout ce que je vous dis à partir de maintenant sera authentifié (et chiffré si le chiffrement a été négocié). » Le ChangeCipherSpec est lui-même un protocole de niveau enregistrement et a le type 20 et non 22.
Enfin, le client envoie un message terminé chiffré , contenant un hachage et un MAC sur les messages de négociation précédents.
Le serveur va tenter de déchiffrer le message terminé du client et de vérifier le hachage et l'adresse MAC. Si le déchiffrement ou la vérification échoue, la négociation est considérée comme ayant échoué et la connexion doit être interrompue.
Enfin, le serveur envoie un ChangeCipherSpec , indiquant au client : « Tout ce que je vous dis à partir de maintenant sera authentifié (et chiffré si le chiffrement a été négocié) ».
Le serveur envoie son propre message de fin chiffré .
Le client exécute la même procédure de décryptage et de vérification que le serveur à l’étape précédente.
Phase d'application : à ce stade, le « handshake » est terminé et le protocole d'application est activé, avec un type de contenu de 23. Les messages d'application échangés entre le client et le serveur seront également cryptés exactement comme dans leur message terminé .
Reprise de la négociation TLS
Les opérations à clé publique (par exemple, RSA) sont relativement coûteuses en termes de puissance de calcul. TLS fournit un raccourci sécurisé dans le mécanisme de négociation pour éviter ces opérations : les sessions reprises. Les sessions reprises sont implémentées à l'aide d'identifiants de session ou de tickets de session.
Outre les avantages en termes de performances, les sessions reprises peuvent également être utilisées pour l'authentification unique , car elles garantissent que la session d'origine et toute session reprise proviennent du même client. Cela est particulièrement important pour le protocole FTP sur TLS/SSL , qui souffrirait sinon d'une attaque de type "man-in-the-middle" dans laquelle un attaquant pourrait intercepter le contenu des connexions de données secondaires.
Poignée de main TLS 1.3
La négociation TLS 1.3 a été condensée en un seul aller-retour par rapport aux deux allers-retours requis dans les versions précédentes de TLS/SSL.
Pour démarrer la négociation, le client devine quel algorithme d'échange de clés sera sélectionné par le serveur et envoie un message ClientHello au serveur contenant une liste de chiffrements pris en charge (par ordre de préférence du client) et des clés publiques pour certaines ou toutes ses suppositions d'échange de clés. Si le client devine avec succès l'algorithme d'échange de clés, 1 aller-retour est éliminé de la négociation. Après avoir reçu le ClientHello , le serveur sélectionne un chiffrement et renvoie un ServerHello avec sa propre clé publique, suivi des messages de certificat et de fin du serveur .
Une fois que le client reçoit le message final du serveur, il est désormais coordonné avec le serveur pour déterminer la suite de chiffrement à utiliser.
ID de session
Lors d'une négociation complète ordinaire , le serveur envoie un identifiant de session dans le cadre du message ServerHello . Le client associe cet identifiant de session à l'adresse IP et au port TCP du serveur, de sorte que lorsque le client se connecte à nouveau à ce serveur, il peut utiliser l' identifiant de session pour raccourcir la négociation. Dans le serveur, l' identifiant de session correspond aux paramètres cryptographiques précédemment négociés, en particulier le « secret maître ». Les deux parties doivent avoir le même « secret maître » ou la reprise de la négociation échouera (cela empêche un espion d'utiliser un identifiant de session ). Les données aléatoires dans les messages ClientHello et ServerHello garantissent pratiquement que les clés de connexion générées seront différentes de celles de la connexion précédente. Dans les RFC, ce type de négociation est appelé négociation abrégée . Il est également décrit dans la littérature comme une négociation de redémarrage .
Phase de négociation :
Un client envoie un message ClientHello spécifiant la version la plus élevée du protocole TLS qu'il prend en charge, un nombre aléatoire, une liste de suites de chiffrement suggérées et des méthodes de compression. Le message comprend l' ID de session de la connexion TLS précédente.
Le serveur répond avec un message ServerHello , contenant la version du protocole choisi, un nombre aléatoire, une suite de chiffrement et une méthode de compression parmi les choix proposés par le client. Si le serveur reconnaît l' ID de session envoyé par le client, il répond avec le même ID de session . Le client l'utilise pour reconnaître qu'une reprise de la négociation est en cours. Si le serveur ne reconnaît pas l' ID de session envoyé par le client, il envoie une valeur différente pour son ID de session . Cela indique au client qu'une reprise de la négociation ne sera pas effectuée. À ce stade, le client et le serveur disposent tous deux du « secret principal » et des données aléatoires pour générer les données clés à utiliser pour cette connexion.
Le serveur envoie maintenant un enregistrement ChangeCipherSpec , indiquant essentiellement au client : « Tout ce que je vous dirai à partir de maintenant sera chiffré. » Le ChangeCipherSpec est lui-même un protocole de niveau enregistrement et a le type 20 et non 22.
Enfin, le serveur envoie un message terminé chiffré , contenant un hachage et un MAC sur les messages de négociation précédents.
Le client va tenter de déchiffrer le message terminé du serveur et de vérifier le hachage et l'adresse MAC. Si le déchiffrement ou la vérification échoue, la négociation est considérée comme ayant échoué et la connexion doit être interrompue.
Enfin, le client envoie un ChangeCipherSpec , indiquant au serveur : « Tout ce que je vous dis à partir de maintenant sera crypté. »
Le client envoie son propre message terminé chiffré .
Le serveur exécute la même procédure de décryptage et de vérification que celle effectuée par le client à l’étape précédente.
Phase d'application : à ce stade, le « handshake » est terminé et le protocole d'application est activé, avec un type de contenu de 23. Les messages d'application échangés entre le client et le serveur seront également cryptés exactement comme dans leur message terminé .
Billets de session
La RFC 5077 étend TLS via l'utilisation de tickets de session, au lieu d'ID de session. Elle définit une manière de reprendre une session TLS sans exiger que l'état spécifique à la session soit stocké sur le serveur TLS.
Lors de l'utilisation de tickets de session, le serveur TLS stocke son état spécifique à la session dans un ticket de session et envoie le ticket de session au client TLS pour stockage. Le client reprend une session TLS en envoyant le ticket de session au serveur, et le serveur reprend la session TLS en fonction de l'état spécifique à la session dans le ticket. Le ticket de session est chiffré et authentifié par le serveur, et le serveur vérifie sa validité avant d'utiliser son contenu.
L'une des faiblesses particulières de cette méthode avec OpenSSL est qu'elle limite toujours la sécurité du chiffrement et de l'authentification du ticket de session TLS transmis à AES128-CBC-SHA256, quels que soient les autres paramètres TLS négociés pour la session TLS réelle. Cela signifie que les informations d'état (le ticket de session TLS) ne sont pas aussi bien protégées que la session TLS elle-même. Le stockage des clés par OpenSSL dans un contexte à l'échelle de l'application ( SSL_CTX), c'est-à-dire pendant toute la durée de vie de l'application, et l'impossibilité de rajouter des clés aux AES128-CBC-SHA256tickets de session TLS sans réinitialiser le contexte OpenSSL à l'échelle de l'application (ce qui est rare, sujet aux erreurs et nécessite souvent une intervention administrative manuelle) sont particulièrement préoccupants.
Enregistrement TLS
Il s'agit du format général de tous les enregistrements TLS.
Type de contenu
Ce champ identifie le type de protocole de couche d'enregistrement contenu dans cet enregistrement.
Version héritée
Ce champ identifie la version majeure et mineure de TLS antérieure à TLS 1.3 pour le message contenu. Pour un message ClientHello, il n'est pas nécessaire que ce soit la version la plus élevée prise en charge par le client. Pour TLS 1.3 et versions ultérieures, ce champ doit être défini sur 0x0303 et l'application doit envoyer les versions prises en charge dans un bloc d'extension de message supplémentaire.
Longueur
La longueur des champs « message(s) de protocole », « MAC » et « remplissage » combinés (c'est-à-dire q −5), ne doit pas dépasser 2 14 octets (16 Ko).
Message(s) de protocole
Un ou plusieurs messages identifiés par le champ Protocole. Notez que ce champ peut être chiffré en fonction de l'état de la connexion.
MAC et rembourrage
Code d'authentification de message calculé sur le champ « message(s) de protocole », avec des éléments de clé supplémentaires inclus. Notez que ce champ peut être chiffré ou ne pas être inclus entièrement, selon l'état de la connexion.
Aucun champ « MAC » ou « padding » ne peut être présent à la fin des enregistrements TLS avant que tous les algorithmes de chiffrement et paramètres n'aient été négociés et échangés, puis confirmés par l'envoi d'un enregistrement CipherStateChange (voir ci-dessous) pour signaler que ces paramètres prendront effet dans tous les enregistrements ultérieurs envoyés par le même homologue.
Protocole de poignée de main
La plupart des messages échangés lors de la configuration de la session TLS sont basés sur cet enregistrement, sauf si une erreur ou un avertissement se produit et doit être signalé par un enregistrement de protocole d'alerte (voir ci-dessous), ou si le mode de chiffrement de la session est modifié par un autre enregistrement (voir le protocole ChangeCipherSpec ci-dessous).
Type de message
Ce champ identifie le type de message de poignée de main.
Longueur des données du message de négociation
Il s'agit d'un champ de 3 octets indiquant la longueur des données de négociation, sans compter l'en-tête.
Notez que plusieurs messages de poignée de main peuvent être combinés dans un seul enregistrement.
Protocole d'alerte
Cet enregistrement ne doit normalement pas être envoyé lors d'un échange normal de handshaking ou d'applications. Cependant, ce message peut être envoyé à tout moment pendant le handshaking et jusqu'à la fermeture de la session. Si cela est utilisé pour signaler une erreur fatale, la session sera fermée immédiatement après l'envoi de cet enregistrement, donc cet enregistrement est utilisé pour donner une raison à cette fermeture. Si le niveau d'alerte est marqué comme un avertissement, la télécommande peut décider de fermer la session si elle décide que la session n'est pas suffisamment fiable pour ses besoins (avant de le faire, la télécommande peut également envoyer son propre signal).
Niveau
Ce champ identifie le niveau d'alerte. Si le niveau est fatal, l'expéditeur doit fermer la session immédiatement. Sinon, le destinataire peut décider de terminer lui-même la session, en envoyant sa propre alerte fatale et en fermant la session elle-même immédiatement après l'avoir envoyée. L'utilisation d'enregistrements d'alerte est facultative, mais s'ils sont manquants avant la fermeture de la session, la session peut être reprise automatiquement (avec ses poignées de main).
La fermeture normale d'une session après la fin de l'application transportée doit de préférence être signalée avec au moins le type d'alerte de notification de fermeture (avec un niveau d'avertissement simple) pour empêcher une telle reprise automatique d'une nouvelle session. Signalant explicitement la fermeture normale d'une session sécurisée avant de fermer effectivement sa couche de transport est utile pour prévenir ou détecter des attaques (comme des tentatives de troncature des données transportées de manière sécurisée, si elles n'ont pas intrinsèquement une longueur ou une durée prédéterminée à laquelle le destinataire des données sécurisées peut s'attendre).
Description
Ce champ identifie le type d’alerte envoyé.
Protocole ChangeCipherSpec
Type de protocole CCS
Actuellement seulement 1.
Protocole d'application
Longueur
Longueur des données d'application (à l'exclusion de l'en-tête du protocole et y compris le MAC et les bandes-annonces de remplissage)
MAC
32 octets pour le HMAC basé sur SHA-256 , 20 octets pour le HMAC basé sur SHA-1 , 16 octets pour le HMAC basé sur MD5 .
Rembourrage
Longueur variable ; le dernier octet contient la longueur de remplissage.
Prise en charge des serveurs virtuels basés sur des noms
Du point de vue du protocole d'application, TLS appartient à une couche inférieure, bien que le modèle TCP/IP soit trop grossier pour le montrer. Cela signifie que la négociation TLS est généralement (sauf dans le cas de STARTTLS ) effectuée avant que le protocole d'application ne puisse démarrer. Dans la fonctionnalité de serveur virtuel basée sur le nom fournie par la couche d'application, tous les serveurs virtuels co-hébergés partagent le même certificat car le serveur doit sélectionner et envoyer un certificat immédiatement après le message ClientHello. Il s'agit d'un problème majeur dans les environnements d'hébergement car cela signifie soit partager le même certificat entre tous les clients, soit utiliser une adresse IP différente pour chacun d'eux.
Il existe deux solutions de contournement connues fournies par X.509 :
Si tous les serveurs virtuels appartiennent au même domaine, un certificat générique peut être utilisé. Outre la sélection approximative du nom d'hôte qui peut poser problème ou non, il n'existe pas d'accord commun sur la manière de faire correspondre les certificats génériques. Différentes règles sont appliquées en fonction du protocole d'application ou du logiciel utilisé.
Ajoutez chaque nom d'hôte virtuel dans l'extension subjectAltName. Le problème majeur est que le certificat doit être réémis à chaque fois qu'un nouveau serveur virtuel est ajouté.
Pour fournir le nom du serveur, les extensions TLS (Transport Layer Security) RFC 4366 permettent aux clients d'inclure une extension SNI ( Server Name Indication ) dans le message ClientHello étendu. Cette extension indique immédiatement au serveur le nom auquel le client souhaite se connecter, afin que le serveur puisse sélectionner le certificat approprié à envoyer aux clients.
Worldlex Wiki 
