TLS et canaux sécurisés

Le protocole Transport Layer Security (TLS) est le protocole qui sécurise la majeure partie des communications Internet, en combinant un échange de clés authentifié et un chiffrement authentifié pour créer un canal confidentiel et protégé en intégrité entre deux points d'extrémité.

Definition

Un protocole de canal sécurisé tel que TLS établit, entre deux parties, une session qui garantit la confidentialité, l'intégrité et l'authentification de toutes les données échangées, en effectuant un échange de clés authentifié suivi d'un chiffrement authentifié du trafic.

Scope

Ce sujet traite des protocoles de canal sécurisé, avec TLS comme exemple central : la poignée de main (handshake) qui authentifie le serveur (et optionnellement le client) et établit les clés de session, la couche d'enregistrement (record layer) qui fournit le chiffrement authentifié, la confidentialité persistante (forward secrecy) et la protection contre la rétrogradation (downgrade protection), ainsi que les leçons tirées des attaques historiques. Il aborde la manière dont les blocs de construction cryptographiques sont assemblés pour former un protocole déployé. Il exclut l'infrastructure de certificats (PKI) et les primitives individuelles, qui sont traitées dans des sujets connexes.

Core questions

• Comment la poignée de main TLS authentifie-t-elle le serveur et s'accorde-t-elle sur les clés de session ?
• Comment la couche d'enregistrement protège-t-elle chaque message avec un chiffrement authentifié ?
• Comment la confidentialité persistante est-elle obtenue, et pourquoi est-elle importante pour le trafic enregistré ?
• Comment les attaques par rétrogradation et renégociation sont-elles évitées ?
• Qu'ont appris les attaques historiques (BEAST, POODLE, Heartbleed) sur la conception des protocoles et des implémentations ?

Key concepts

• Poignée de main TLS
• Couche d'enregistrement
• Chiffrement authentifié (AEAD)
• Échange de clés éphémères (ECDHE)
• Confidentialité persistante
• Authentification du serveur et du client
• Attaques par rétrogradation et renégociation
• Reprise de session
• Négociation de la suite de chiffrement

Key theories

Protocole de poignée de main et d'enregistrement

TLS sépare une poignée de main d'échange de clés authentifiée — qui vérifie l'identité via des certificats et dérive les clés de session — d'une couche d'enregistrement qui chiffre et authentifie les données d'application avec ces clés, composant proprement l'authentification, l'accord de clés et la protection en masse.

Confidentialité persistante et protection contre la rétrogradation

TLS 1.3 impose le Diffie-Hellman éphémère (à courbe elliptique) pour la confidentialité persistante et lie la transcription de la poignée de main au calendrier des clés afin qu'un attaquant actif ne puisse pas forcer une rétrogradation vers des paramètres plus faibles sans être détecté.

Mechanisms

Dans TLS 1.3, le client envoie ses parts d'échange de clés et les paramètres pris en charge ; le serveur répond avec sa propre part Diffie-Hellman éphémère, son certificat et une signature sur la transcription de la poignée de main (handshake), et les deux parties dérivent les clés de session via une fonction de dérivation de clés (HKDF). La couche d'enregistrement protège ensuite toutes les données avec un chiffrement AEAD (tel que AES-GCM ou ChaCha20-Poly1305). La transcription est authentifiée pour empêcher toute altération ou rétrogradation, et la poignée de main se termine en un seul aller-retour, avec une reprise optionnelle sans aller-retour (zero-round-trip resumption).

Clinical relevance

TLS sécurise l'écrasante majorité du trafic Internet : HTTPS pour le web, le transport sécurisé des e-mails, les API, les VPN et la messagerie fonctionnent tous via ce protocole. Sa justesse détermine directement si les mots de passe, les paiements et les données personnelles sont protégés contre les attaquants réseau. La migration de SSL/TLS précoce défectueux vers TLS 1.3 — et l'analyse qui l'a accompagnée — constitue un modèle pour l'évolution des protocoles sous la pression du monde réel.

Evidence & guidelines

TLS 1.3 est normalisé dans la RFC 8446 et est recommandé ; SSL 3.0, TLS 1.0 et TLS 1.1 sont obsolètes (RFC 8996). Le NIST SP 800-52 fournit des directives de configuration. TLS 1.3 a été développé avec une analyse formelle approfondie, éliminant les faiblesses héritées (échange de clés RSA statique, mode CBC, renégociation) qui ont permis des attaques antérieures telles que BEAST, POODLE et la faille d'implémentation Heartbleed.

History

Netscape a créé SSL en 1994-1995 ; SSL 3.0 a été repensé par l'IETF en tant que TLS 1.0 (1999) et affiné jusqu'à TLS 1.2 (2008). Une décennie d'attaques — BEAST, CRIME, POODLE, le bogue d'implémentation Heartbleed, Logjam et FREAK — a révélé des faiblesses dans les modes hérités et la gestion de la rétrogradation. TLS 1.3 (RFC 8446, 2018) a constitué une refonte majeure avec une confidentialité persistante obligatoire, une poignée de main plus rapide et une analyse de sécurité formelle.

Key figures

• Eric Rescorla
• Hugo Krawczyk
• Kenny Paterson
• Taher ElGamal

Seminal works

• rfc8446
• stallings2017
• katz2020

Frequently asked questions

Quelle est la différence entre SSL et TLS ?

TLS est le successeur de SSL. SSL (versions 2.0 et 3.0) est obsolète et non sécurisé ; le terme 'SSL' persiste comme appellation courante, mais toutes les connexions web sécurisées actuelles utilisent TLS, TLS 1.3 étant la version moderne.

TLS me protège-t-il d'un site web malveillant ?

TLS garantit uniquement que vous disposez d'un canal confidentiel et authentifié vers le serveur nommé dans le certificat — il confirme que vous communiquez avec ce domaine, et non que le domaine est digne de confiance. Un site de phishing peut servir un certificat valide pour son propre domaine (similaire), donc TLS ne se porte pas garant de l'honnêteté du site.