TLS (Transport Layer Security)
TLS (Transport Layer Security) est le protocole qui chiffre et authentifie une connexion réseau, à commencer par celle d'un navigateur vers un serveur web sur le port 443. C'est le successeur direct de SSL : la version de référence aujourd'hui est TLS 1.3, publiée en août 2018 dans la RFC 8446, et TLS 1.2 (RFC 5246) reste largement accepté.
Ce que TLS chiffre, et ce qu’il laisse visible
Vous ouvrez https://exemple.fr. Avant qu'un seul octet de requête HTTP ne circule, le navigateur établit une connexion TCP sur le port 443 puis lance une négociation TLS. Le serveur présente un certificat X.509, les deux parties se mettent d'accord sur un algorithme et dérivent des clés de session valables pour cette connexion seulement. Tout ce qui suit part chiffré, en-têtes HTTP et cookies compris.
TLS s'intercale juste au-dessus de TCP et en dessous du protocole applicatif. C'est ce découpage qui lui permet de servir HTTP, SMTP, IMAP, LDAP ou DNS sans qu'aucun de ces protocoles n'ait à gérer lui-même de la cryptographie. La couche record découpe le flux en blocs de 16 384 octets de texte clair au maximum, chiffre chaque bloc et y attache un tag d'authentification : modifier un seul octet en transit fait échouer la vérification et coupe la connexion.
Ce que TLS ne cache pas mérite d'être connu, parce que sa portée est régulièrement surestimée.
L'extension ECH (Encrypted Client Hello) vise justement à chiffrer le SNI, mais elle reste à l'état de brouillon à l'IETF et son activation dépend d'un enregistrement DNS de type HTTPS côté serveur. Ne construisez pas une promesse de confidentialité dessus sans vérifier ce que vos clients réels supportent.
- L'adresse IP du serveur contacté, en clair dans l'en-tête IP
- Le nom d'hôte demandé, transmis en clair dans l'extension SNI du ClientHello
- La résolution DNS qui a précédé, sauf si le client utilise DoT (port 853) ou DoH
- Le volume, la taille et le rythme des paquets, souvent suffisants pour deviner quelle page a été consultée
Le handshake : un aller-retour en TLS 1.3, deux en TLS 1.2
En TLS 1.3, la poignée de main tient en un seul aller-retour. Le client envoie un ClientHello qui contient déjà sa part de clé Diffie-Hellman éphémère (extension key_share), la liste des suites qu'il accepte et l'extension supported_versions. Le serveur répond avec sa propre part de clé dans le ServerHello, puis chiffre immédiatement la suite : son certificat, sa signature et le message Finished voyagent déjà protégés.
En TLS 1.2, il fallait deux allers-retours complets et le certificat du serveur passait en clair sur le réseau. Sur une liaison à 50 ms de latence, l'écart représente environ 100 ms rendus au visiteur à chaque nouvelle connexion, avant même le premier octet de HTML.
TLS 1.3 ajoute un mode 0-RTT : si le client a déjà parlé au serveur, il peut joindre des données applicatives dès son premier paquet grâce à une clé pré-partagée. Le gain est réel, le risque aussi. La RFC 8446 précise que ces early data sont rejouables par un attaquant qui capture le paquet. N'autorisez le 0-RTT que sur des requêtes idempotentes, jamais sur un POST qui débite un compte ou crée une commande.
Une session négociée se lit directement dans la sortie d'openssl s_client : « Protocol : TLSv1.3 », « Cipher : TLS_AES_256_GCM_SHA384 », « Server Temp Key : X25519, 253 bits ». Ces trois lignes donnent la version, l'algorithme AEAD et la courbe utilisée pour l'échange de clés.
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| RFC et date | 5246, août 2008 | 8446, août 2018 |
| Allers-retours avant données | 2 | 1 (0 en reprise de session) |
| Échange de clés | RSA, DHE, ECDHE | ECDHE ou DHE uniquement |
| Confidentialité persistante | Optionnelle | Obligatoire par construction |
| Chiffrements | CBC, RC4, AEAD | AEAD seulement : AES-GCM, AES-CCM, ChaCha20-Poly1305 |
| Suites définies | Plusieurs dizaines | 5 |
| Certificat du serveur | Envoyé en clair | Chiffré dès après le ServerHello |
| Renégociation, compression | Présentes | Supprimées |
Les versions et leur statut réel
TLS 1.0 et TLS 1.1 sont formellement dépréciés par la RFC 8996 depuis mars 2021, et les quatre navigateurs majeurs les avaient déjà coupés courant 2020. Si un terminal de paiement, une imprimante réseau ou un automate industriel vous oblige à en garder un, isolez-le derrière un proxy dédié sur un vhost séparé plutôt que de rouvrir la version sur le service principal.
Un détail qui déroute en analyse de trame : un ClientHello TLS 1.3 annonce 0x0303 dans son champ legacy_version, c'est-à-dire TLS 1.2. La vraie version se lit dans l'extension supported_versions (numéro 43). Ce camouflage a été ajouté au standard parce que trop de pare-feux et de répartiteurs de charge rejetaient purement et simplement les numéros de version qu'ils ne connaissaient pas.
| Version | Code sur 2 octets | Publication | Statut |
|---|---|---|---|
| SSL 2.0 | 0x0002 | 1995 | Interdit (RFC 6176) |
| SSL 3.0 | 0x0300 | 1996 | Interdit (RFC 7568) |
| TLS 1.0 | 0x0301 | 1999 (RFC 2246) | Déprécié (RFC 8996) |
| TLS 1.1 | 0x0302 | 2006 (RFC 4346) | Déprécié (RFC 8996) |
| TLS 1.2 | 0x0303 | 2008 (RFC 5246) | Accepté, à durcir côté suites |
| TLS 1.3 | 0x0304 | 2018 (RFC 8446) | Recommandé |
SSL, TLS, HTTPS, certificat : qui fait quoi
SSL et TLS désignent le même protocole à deux moments de son histoire. Netscape publie SSL 2.0 en 1995 puis SSL 3.0 en 1996. Quand l'IETF reprend le dossier, la version suivante est renommée TLS 1.0. Dire « SSL » en 2026 pour parler d'une connexion chiffrée est donc un raccourci de langage, pas une erreur de fond, mais le protocole qui portait ce nom est interdit depuis dix ans.
« Certificat SSL » relève du même héritage. L'objet que vend une autorité de certification est un certificat X.509 : il lie une clé publique à un ou plusieurs noms de domaine et il est signé par une AC présente dans le magasin de confiance du client. Il ne chiffre rien par lui-même. Le chiffrement vient de la clé de session dérivée pendant le handshake ; le certificat sert uniquement à prouver que vous parlez au bon serveur, ce qui bloque l'interception active.
Sur la durée de vie, le CA/Browser Forum plafonne les certificats TLS publics à 398 jours depuis septembre 2020, avec une réduction progressive votée en 2025 : 200 jours à partir de mars 2026, puis 100 jours en 2027 et 47 jours en 2029. Let's Encrypt émet de son côté des certificats de 90 jours, ce qui rend l'automatisation via ACME obligatoire en pratique.
HTTPS n'est pas un protocole distinct : c'est HTTP transporté dans TLS. Le même mécanisme habille d'autres services selon deux modèles, le TLS implicite (la session est chiffrée dès l'ouverture du socket) et STARTTLS (la connexion démarre en clair puis bascule sur commande, RFC 3207 pour SMTP).
Dernière confusion fréquente : TLS protège le transport, pas le contenu au repos. Derrière un CDN, un reverse proxy ou un boîtier d'inspection qui termine la session, les données sont déchiffrées puis rechiffrées. À cet endroit précis, l'intermédiaire voit tout en clair. Ce n'est pas du chiffrement de bout en bout, quel que soit l'aspect du cadenas dans la barre d'adresse.
- 443 : HTTPS en TCP, et HTTP/3 sur QUIC en UDP au même numéro (QUIC embarque le handshake TLS 1.3, RFC 9001)
- 465 : soumission SMTP en TLS implicite
- 587 : soumission SMTP avec STARTTLS
- 993 : IMAP sur TLS
- 995 : POP3 sur TLS
- 636 : LDAPS
- 853 : DNS over TLS (RFC 7858)
Vérifier et dépanner une configuration TLS
La commande de référence tient en une ligne : openssl s_client -connect exemple.fr:443 -servername exemple.fr. L'option -servername envoie le SNI et devient obligatoire dès qu'un serveur héberge plusieurs vhosts. Sans elle, vous recevez le certificat par défaut de la machine et vous concluez à tort à une erreur de configuration.
Pour cibler une version, ajoutez -tls1_2 ou -tls1_3 : un échec immédiat vous dit que le serveur la refuse. Pour les dates de validité sans lire tout le certificat : echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null | openssl x509 -noout -dates. Pour l'inventaire des suites acceptées, nmap --script ssl-enum-ciphers -p 443 exemple.fr sort la liste complète avec une note par suite.
La panne la plus courante n'est pas le certificat expiré, c'est la chaîne incomplète. Vous installez le certificat feuille en oubliant l'intermédiaire. Chrome et Firefox s'en sortent : ils récupèrent l'intermédiaire manquant via l'extension AIA ou l'ont déjà en cache. curl, Java, Python requests et les vieux Android, non. Résultat classique : le site s'affiche parfaitement dans votre navigateur pendant qu'un appel serveur à serveur renvoie « unable to get local issuer certificate ». Le test qui tranche est openssl s_client -connect exemple.fr:443 -servername exemple.fr -showcerts : la sortie doit lister la feuille et l'intermédiaire, et la ligne « Verify return code » doit valoir 0 (ok).
Les codes d'alerte TLS accélèrent le diagnostic quand vous les lisez dans une capture Wireshark ou dans les logs.
Une fois la configuration propre, l'en-tête Strict-Transport-Security: max-age=31536000; includeSubDomains (HSTS, RFC 6797) interdit au navigateur toute retombée en HTTP pendant un an. Testez avec une valeur courte d'abord : tant que la directive est en cache côté client, vous ne pouvez pas revenir en arrière sans attendre l'expiration.
- 40 handshake_failure : aucune version ni aucune suite en commun entre le client et le serveur
- 42 bad_certificate : certificat illisible ou signature invalide
- 45 certificate_expired : date dépassée, ou horloge du client désynchronisée
- 48 unknown_ca : l'AC signataire est absente du magasin du client, cas typique d'une chaîne incomplète ou d'une AC interne non déployée
- 70 protocol_version : le client réclame une version que le serveur refuse
- 112 unrecognized_name : le SNI envoyé ne correspond à aucun vhost configuré
Testez vos connaissances
Quelle RFC définit TLS 1.3 ?
Score : 0 sur 3
Questions fréquentes
TLS et SSL, est-ce la même chose ?
Le même protocole à deux époques. SSL 3.0 date de 1996 et de Netscape ; TLS 1.0 en est le successeur direct, publié par l'IETF en 1999 dans la RFC 2246. Toutes les versions SSL sont aujourd'hui interdites : SSL 2.0 par la RFC 6176, SSL 3.0 par la RFC 7568 après l'attaque POODLE. Quand un prestataire vous vend un « certificat SSL », il vous vend un certificat X.509 qui sera utilisé par TLS.
Faut-il encore accepter TLS 1.0 et TLS 1.1 sur un serveur web ?
Non pour du trafic public. La RFC 8996 les a dépréciés en mars 2021, les navigateurs les ont coupés en 2020, et le PCI DSS impose TLS 1.2 au minimum depuis le 30 juin 2018 dès qu'il y a des données de carte. Le seul cas défendable est un équipement ancien qui ne sait rien faire d'autre : mettez-le derrière un proxy sur un vhost séparé, pas sur le service principal.
TLS 1.3 est-il réellement plus rapide ?
Sur l'établissement de connexion, oui : un aller-retour au lieu de deux. Sur un lien à 50 ms de RTT, cela retire environ 100 ms avant le premier octet utile, et davantage sur mobile. Une fois la session ouverte, le débit dépend surtout de l'algorithme : AES-GCM profite de l'accélération matérielle (AES-NI sur x86, extensions cryptographiques ARMv8), tandis que ChaCha20-Poly1305 prend l'avantage sur les processeurs qui en sont dépourvus, typiquement des mobiles d'entrée de gamme.
Un certificat gratuit chiffre-t-il moins bien qu’un certificat payant ?
Le canal chiffré est identique : la classe du certificat n'entre pas dans la dérivation des clés de session. Ce qui change, c'est le niveau de validation (DV, OV, EV), la garantie financière et le support. Un certificat Let's Encrypt en DV valide 90 jours donne exactement la même qualité de chiffrement qu'un EV facturé plusieurs centaines d'euros. Depuis 2019, aucun navigateur majeur n'affiche plus la raison sociale dans la barre d'adresse pour les certificats EV.
TLS suffit-il à parler de chiffrement de bout en bout ?
Non. TLS protège un segment, du client jusqu'au point où la session se termine. Si un CDN, un répartiteur de charge ou un pare-feu d'inspection termine TLS, les données sont en clair à cet endroit avant d'être rechiffrées vers l'origine. Pour du bout en bout véritable, il faut chiffrer le contenu lui-même avant l'envoi, comme le fait OpenPGP pour un e-mail.
À lire aussi
certificat ssl · chiffrement asymetrique · chiffrement symetrique · attaque man in the middle