Négociation TLS 1.3 et reprise 0-RTT

TLS 1.3, publié en 2018 (RFC 8446), a été conçu pour corriger les faiblesses qui s'étaient accumulées dans TLS 1.2 au fil d'une décennie d'attaques réelles. Les versions précédentes permettaient de négocier des suites cryptographiques faibles, prenaient en charge la cryptographie de niveau exportation et exigeaient plusieurs allers-retours avant que les données puissent circuler. TLS 1.3 supprime tous les algorithmes obsolètes et simplifie l'établissement de la connexion à un seul aller-retour dans le cas normal, ce qui améliore considérablement à la fois la sécurité et les performances.

Dans TLS 1.3, le client et le serveur terminent l'établissement de la connexion en 1-RTT (un aller-retour). Le client envoie un ClientHello qui inclut les suites cryptographiques prises en charge et un partage de clé (utilisant Diffie-Hellman). Le serveur répond avec un ServerHello, son propre partage de clé, un certificat et les premières données d'application chiffrées — le tout en un seul échange. Le client vérifie ensuite le certificat et envoie un message Finished avant d'échanger les données d'application.

TLS 1.3 impose un échange de clés éphémères : il a supprimé entièrement l'échange de clés RSA. Tout échange de clés doit utiliser ECDHE (Diffie-Hellman éphémère sur courbe elliptique) ou DHE (Diffie-Hellman éphémère). Le terme « éphémère » signifie qu'une nouvelle paire de clés est générée pour chaque session. C'est le fondement de la perfect forward secrecy : la compromission de la clé privée à long terme du serveur ne permet pas de déchiffrer les sessions passées, car chaque session utilisait une clé temporaire unique.

La Perfect Forward Secrecy (PFS) garantit que, même si un attaquant enregistre aujourd'hui tout le trafic chiffré et obtient ultérieurement la clé privée du serveur, il ne pourra toujours pas déchiffrer les anciennes sessions. Dans TLS 1.2 avec échange de clés RSA, la clé privée du serveur pouvait déchiffrer le secret prém maître de toute session passée — une défaillance catastrophique. Les clés DH éphémères de TLS 1.3 signifient que chaque session dérive ses propres clés et que ces clés éphémères sont supprimées après utilisation.

TLS 1.2 prenait en charge plus de 300 suites cryptographiques, dont beaucoup étaient faibles ou compromises. TLS 1.3 réduit ce nombre à seulement cinq suites cryptographiques, qui utilisent toutes AEAD (chiffrement authentifié avec Data associées) : TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 et TLS_AES_128_CCM_8_SHA256. Cela élimine des catégories entières d'attaques comme BEAST, POODLE et FREAK, qui exploitaient la négociation de chiffrements faibles.

La reprise 0-RTT (Zero Round Trip Time) est une fonctionnalité facultative de TLS 1.3 qui permet à un client d'envoyer des données d'application dès son tout premier message, avant la fin de l'établissement de la connexion. Elle fonctionne grâce à une Pre-Shared Key (PSK) issue d'une session précédente. Bien que le 0-RTT réduise considérablement la latence — ce qui est essentiel pour les API à fort trafic —, il introduit un compromis important : les premières données ne sont pas protégées contre les attaques par rejeu.

Lors d'une attaque par rejeu visant des données 0-RTT, un attaquant qui intercepte le message de premières données peut le renvoyer au serveur et potentiellement déclencher deux fois la même action (par exemple, un paiement ou une modification d'état). La spécification de TLS 1.3 avertit explicitement que les premières données 0-RTT ne doivent transporter que des opérations idempotentes — c'est-à-dire des opérations qui produisent le même résultat quel que soit le nombre de leurs exécutions, comme une requête GET. Les opérations non idempotentes (POST, DELETE) ne doivent jamais utiliser le 0-RTT.

Après un établissement complet de la connexion TLS 1.3 réussi, le serveur émet un message NewSessionTicket contenant une PSK (Pre-Shared Key) que le client conserve. Lors de la reconnexion, le client inclut cette PSK dans son ClientHello à l'aide de l'extension pre_shared_key. Le serveur la reconnaît et autorise les données 0-RTT ou revient à une reprise 1-RTT. Les tickets PSK sont limités dans le temps et doivent être renouvelés fréquemment afin de réduire leur fenêtre d'exposition.

Une amélioration majeure de TLS 1.3 est que la majeure partie de l'établissement de la connexion est chiffrée, y compris le certificat du serveur. Dans TLS 1.2, le certificat du serveur était envoyé en clair, ce qui permettait à un observateur du réseau d'identifier le domaine auquel le client se connectait. TLS 1.3 chiffre le certificat et la plupart des messages ultérieurs d'établissement de la connexion, réduisant les métadonnées accessibles aux observateurs passifs. Encrypted Client Hello (ECH) est une extension émergente qui dissimule même le champ SNI (Server Name Indication).

TLS 1.3 a supprimé de nombreuses fonctionnalités historiques devenues des faiblesses : l'échange de clés RSA (sans perfect forward secrecy), les suites cryptographiques en mode CBC (vulnérables aux attaques par oracle de bourrage), RC4 (chiffrement par flux complètement compromis), la cryptographie de niveau exportation (à l'origine de FREAK et de Logjam), MD5 et SHA-1 dans les signatures numériques, la compression (à l'origine de CRIME) et la renégociation (à l'origine de plusieurs attaques). En les supprimant, TLS 1.3 possède une surface d'attaque considérablement réduite.

Déployer correctement TLS 1.3 nécessite de configurer votre serveur web pour le privilégier tout en désactivant TLS 1.0 et 1.1. La plupart des serveurs web modernes (Nginx, Apache, IIS) prennent nativement TLS 1.3 en charge. Vous devez également vérifier que l'OCSP Stapling est activé afin de fournir l'état de révocation du certificat sans que le client contacte l'autorité de certification, et que les en-têtes HSTS empêchent les attaques par rétrogradation vers HTTP. Utilisez des outils tels que SSL Labs pour vérifier que votre configuration obtient la note A+.

Testez votre compréhension des notions de CompTIA Security+ (SY0-701) présentées dans cette leçon.

Dans cette leçon, vous avez appris que TLS 1.3 termine l'établissement de la connexion en 1-RTT en utilisant uniquement un échange de clés DH éphémères pour assurer la perfect forward secrecy ; que la reprise 0-RTT permet une reconnexion plus rapide grâce aux PSK, mais reste vulnérable aux attaques par rejeu et ne doit transporter que des opérations idempotentes ; et que TLS 1.3 supprime toutes les fonctionnalités faibles historiques — échange de clés RSA, chiffrements CBC, RC4, cryptographie d'exportation et compression —, réduisant considérablement la surface d'attaque. Nous allons maintenant étudier des algorithmes de chiffrement authentifié tels que AES-GCM.