Comprendre TLS : mécanismes, garanties et limites
Comprendre TLS : mécanismes, garanties et limites
Section intitulée « Comprendre TLS : mécanismes, garanties et limites »Transport Layer Security (TLS) est le protocole qui protège la majorité des communications applicatives sur Internet, à commencer par HTTPS (HyperText Transfer Protocol Secure). Il combine chiffrement, contrôle d’intégrité et authentification pour établir un canal sécurisé, historiquement au-dessus de TCP (Transmission Control Protocol) ; son handshake sert aussi de socle cryptographique à QUIC (Quick UDP Internet Connections). Cet article décrit les mécanismes de TLS, les garanties qu’il apporte réellement et les limites qu’il convient de connaître avant de s’appuyer dessus.
→ Lire l’explication complète de la marmotte
Les objectifs de TLS
Section intitulée « Les objectifs de TLS »TLS vise trois propriétés complémentaires sur un canal de communication :
- Confidentialité : le contenu échangé est chiffré, un observateur du réseau ne peut pas le lire.
- Intégrité : toute altération des données en transit est détectée grâce au chiffrement authentifié avec données associées (AEAD).
- Authentification : au moins l’une des deux parties prouve son identité. En pratique, l’authentification du serveur est quasi systématique, mais elle dépend de la configuration et de la suite cryptographique retenue : le protocole autorise historiquement des suites anonymes, sans certificat, qui ne fournissent aucune authentification. L’authentification du client reste optionnelle et relève de mTLS.
Ces garanties reposent sur une combinaison de cryptographie asymétrique (pour l’établissement de clé et la vérification d’identité) et de cryptographie symétrique (pour le chiffrement du trafic une fois le canal établi). Le glossaire TLS rappelle les définitions de base.
Le déroulement d’une négociation TLS
Section intitulée « Le déroulement d’une négociation TLS »La version moderne du protocole, TLS 1.3, réduit la négociation (le handshake) à un seul aller-retour dans le cas nominal. Le déroulement simplifié est le suivant.
Étape 1 : ClientHello
Section intitulée « Étape 1 : ClientHello »Le client envoie un message ClientHello contenant les versions de protocole supportées, la liste des suites cryptographiques proposées et un ou plusieurs key_share : ses composantes publiques éphémères pour l’échange de clé.
Étape 2 : ServerHello
Section intitulée « Étape 2 : ServerHello »Le serveur répond par un ServerHello qui fixe la suite cryptographique retenue et fournit son propre key_share. Le ServerHello ne contient pas le certificat du serveur : celui-ci est transmis dans un message Certificate distinct, envoyé après le ServerHello et déjà chiffré sous les clés de handshake.
Étape 3 : Dérivation des clés
Section intitulée « Étape 3 : Dérivation des clés »Une fois les key_share du client et du serveur échangés, chaque partie calcule un secret partagé. TLS 1.3 s’appuie sur un échange Diffie-Hellman éphémère, réalisable soit sur courbes elliptiques (ECDHE, Elliptic Curve Diffie-Hellman Ephemeral), soit sur corps fini, DHE (Diffie-Hellman Ephemeral). Le secret brut issu de cet échange n’est pas utilisé directement : il alimente une fonction de dérivation de clé, HKDF (HMAC-based Key Derivation Function), qui produit des clés distinctes pour le handshake puis pour le trafic applicatif.
Point important sur la chronologie : le chiffrement du handshake commence juste après l’échange des key_share. Tous les messages qui suivent le ServerHello, y compris le message Certificate et la vérification de signature du serveur, sont donc déjà protégés par les clés de handshake dérivées à cette étape.
Étape 4 : Vérification et finalisation
Section intitulée « Étape 4 : Vérification et finalisation »Le client vérifie le certificat reçu (chaîne de confiance, validité, nom de domaine) et contrôle la signature du serveur sur les paramètres du handshake. Un message Finished de part et d’autre scelle la négociation en authentifiant l’ensemble des échanges précédents. Le canal chiffré est alors prêt pour les données applicatives.
Certificats, identité et confiance
Section intitulée « Certificats, identité et confiance »L’authentification du serveur repose sur un certificat X.509 signé par une autorité de certification. La chaîne de confiance relie ce certificat à une racine présente dans le magasin du client. La vérification porte notamment sur :
- la validité temporelle du certificat ;
- la correspondance entre le nom demandé et le champ
subjectAltName; - la non-révocation, via des mécanismes comme OCSP (Online Certificate Status Protocol) ou les listes de révocation.
Ces principes relèvent de l’infrastructure à clés publiques (PKI), détaillée dans PKI expliquée. TLS ne garantit que le lien cryptographique entre une clé et un nom : la confiance dans l’autorité qui a émis le certificat reste une hypothèse externe.
Échange de clés et forward secrecy
Section intitulée « Échange de clés et forward secrecy »L’utilisation systématique d’un échange Diffie-Hellman éphémère (ECDHE ou DHE) confère à TLS 1.3 la propriété de forward secrecy : la compromission ultérieure de la clé privée long terme du serveur ne permet pas de déchiffrer les sessions passées.
Le mécanisme se décompose ainsi :
- chaque partie génère une paire éphémère (privée/publique) propre à la session ;
- l’échange des composantes publiques produit un secret partagé ECDHE (ou DHE) ;
- ce secret est injecté dans HKDF, avec les transcriptions du handshake, pour dériver les clés de session.
Comme les clés privées éphémères sont détruites après la session, aucune donnée persistante ne permet de reconstituer le secret partagé. C’est cette destruction, et non la seule clé du certificat, qui fonde la forward secrecy. La sécurisation d’un canal approfondit ces notions.
Exemple : inspecter une négociation TLS
Section intitulée « Exemple : inspecter une négociation TLS »La commande suivante affiche le certificat présenté et la version de protocole négociée avec un serveur :
openssl s_client -connect example.org:443 -servername example.org -tls1_3 </dev/nullLa sortie indique la suite cryptographique retenue (par exemple TLS_AES_256_GCM_SHA384), la chaîne de certificats et le résultat de la vérification. Un code Verify return code: 0 (ok) confirme que la chaîne a été validée jusqu’à une racine de confiance.
Limites de TLS
Section intitulée « Limites de TLS »TLS protège le canal, pas les extrémités. Plusieurs limites doivent être gardées à l’esprit :
- Métadonnées : les tailles, les horodatages et certaines informations d’établissement (nom de serveur) peuvent fuiter. L’extension Encrypted ClientHello vise à réduire cette exposition lorsque le support existe.
- Compromission d’une extrémité : si le serveur ou le client est compromis, le chiffrement en transit n’apporte aucune protection sur les données au repos.
- Confiance dans les autorités : une autorité de certification malveillante ou compromise peut émettre un certificat frauduleux.
- Configuration : les suites anonymes, les versions obsolètes ou une validation de certificat désactivée annulent une partie des garanties. La protection contre les attaques par repli (downgrade) dépend d’une configuration correcte.
- 0-RTT : la reprise anticipée en TLS 1.3 offre un gain de latence, mais les données 0-RTT sont susceptibles d’être rejouées et n’offrent pas la même forward secrecy.
Lien avec mTLS et la PKI
Section intitulée « Lien avec mTLS et la PKI »Lorsque l’authentification du client est également requise, TLS s’étend en authentification mutuelle : chaque partie présente et vérifie un certificat. Ce mode est décrit dans mTLS. L’ensemble s’inscrit dans une infrastructure de gestion des certificats couverte par la section PKI et TLS. Pour la sécurisation de la résolution de noms, voir DNS TLS.
TLS chiffre-t-il le nom du serveur contacté ?
Section intitulée « TLS chiffre-t-il le nom du serveur contacté ? »Historiquement, le nom du serveur (Server Name Indication) circule en clair dans le ClientHello, ce qui permet à un observateur de savoir quel domaine est visé. L’extension Encrypted ClientHello vise à chiffrer cette information, mais son déploiement dépend du support côté client et côté serveur.
La forward secrecy est-elle toujours active en TLS 1.3 ?
Section intitulée « La forward secrecy est-elle toujours active en TLS 1.3 ? »Oui pour les échanges initiaux : TLS 1.3 impose un échange Diffie-Hellman éphémère (ECDHE ou DHE), ce qui garantit la forward secrecy. En revanche, les données envoyées en 0-RTT lors d’une reprise de session n’en bénéficient pas de la même manière et peuvent être rejouées.
Un certificat valide suffit-il à prouver que le site est légitime ?
Section intitulée « Un certificat valide suffit-il à prouver que le site est légitime ? »Non. Un certificat valide prouve seulement qu’une autorité reconnue a lié une clé publique à un nom de domaine. Il ne garantit ni l’honnêteté de l’exploitant du domaine, ni l’absence de compromission du serveur ; il ne protège pas non plus contre un domaine ressemblant obtenu légitimement par un attaquant.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans TLS correctement configuré, le réseau redevient un lieu de lecture et d’écriture pour quiconque s’y trouve. Un client qui désactive la vérification du certificat chiffre soigneusement ses données, mais pour le premier intermédiaire venu, qui déchiffre, lit, modifie et rechiffre sans que rien ne s’affiche. Des versions obsolètes laissées actives permettent à l’attaquant de forcer le repli, puis de s’en prendre à la protection la plus faible encore acceptée. Sans échange éphémère, une clé privée volée un jour déverrouille rétroactivement tout le trafic enregistré jusque-là. Et les données envoyées en reprise anticipée, rejouables par construction, peuvent déclencher deux fois une même opération si l’application ne s’en est pas prémunie.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Le protocole TLS, pour sécurité de la couche de transport, protège la plupart des échanges sur Internet, notamment les pages web dont l’adresse commence par https. Il vise trois garanties : un observateur ne peut pas lire le contenu, toute modification en chemin est détectée, et au moins l’un des deux côtés, en pratique le serveur, prouve son identité. La connexion commence par une négociation. Le client envoie les versions et les méthodes de chiffrement qu’il accepte, ainsi qu’une valeur publique fabriquée pour cette seule connexion. Le serveur choisit une méthode et renvoie sa propre valeur publique. Avec ces deux valeurs, chaque côté calcule le même secret sans jamais le transmettre, puis en tire des clés distinctes pour la suite. Le serveur envoie ensuite, déjà chiffré, son certificat : un document signé par une autorité reconnue qui relie son nom à sa clé. Le client vérifie la chaîne d’autorités, les dates, le nom et une signature du serveur. Un dernier message de chaque côté confirme que tout l’échange est intact. Comme les valeurs temporaires sont détruites après la connexion, voler plus tard la clé du serveur ne permet pas de déchiffrer les échanges passés. Les limites restent réelles : la taille, l’heure et souvent le nom du site visité restent visibles ; un ordinateur piraté à l’une des extrémités n’est pas protégé ; une autorité malhonnête peut émettre un faux certificat ; des réglages anciens annulent une partie des garanties.
À lire aussi
- La poignée de main TLS 1.3 en une pageClientHello, ServerHello, dérivation des clés, certificat chiffré et Finished : la poignée de main TLS 1.3 (RFC 8446) animée en six étapes, avec le 0-RTT et ses risques de rejeu.
- Migrer TLS legacy sans casser les clients anciensMéthode de migration d'une infrastructure TLS legacy vers TLS moderne en préservant temporairement les clients anciens encore nécessaires.
- Établir une clé : Diffie-Hellman, KEM et HPKEÉtablir une clé sans canal sécurisé : Diffie-Hellman pour fabriquer le secret commun, KEM pour l'interface encapsuler/décapsuler, HPKE (RFC 9180) pour assembler KEM, KDF et AEAD.
- Extensions X.509 v3 Key Usage EKU et Basic ConstraintsDétail des extensions X.509 v3 Key Usage, Extended Key Usage et Basic Constraints, avec leurs implications de sécurité et d’exploitation.
Pages voisines
La citent
- Certificate pinning : risques et rotation des certificats
- Certificats SSH et risques de l’agent forwarding
- Choisir ECDSA, EdDSA ou RSA pour un certificat TLS
- Construire une autorité de certification privée interne
- Diagnostiquer les erreurs de validation TLS en production
- Intégrer la cryptographie post-quantique dans TLS
- Migrer TLS legacy sans casser les clients anciens
Comprendre TLS : mécanismes, garanties et limites
Elle cite
: les deux pages se citent l’une l’autre.