Comprendre TLS : mécanismes, garanties et limites

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.

TortueTech Débutant · Intermédiaire

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

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

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

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

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

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

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

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 :

1. chaque partie génère une paire éphémère (privée/publique) propre à la session ;
2. l’échange des composantes publiques produit un secret partagé ECDHE (ou DHE) ;
3. 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 et l’établissement de clé Diffie-Hellman approfondissent ces notions.

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/null

La 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

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

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.

FAQ

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 ?

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 ?

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.