TLS 1.3 : 0-RTT, données précoces et reprise de session

TLS 1.3 (RFC 8446, 2018) a repensé la négociation TLS afin de réduire la latence et de supprimer les éléments hérités superflus. Une négociation TLS 1.3 complète s’achève en 1-RTT : le client envoie ClientHello avec les key_shares pris en charge (clés publiques ECDH éphémères) lors de la première volée ; le serveur répond avec ServerHello, son key_share, EncryptedExtensions, son certificat et son message de fin, le tout dans une seule réponse. Le client envoie ensuite son message de fin et peut immédiatement transmettre des données applicatives. Par rapport à la négociation en 2-RTT de TLS 1.2, cela réduit de moitié le temps d’établissement des nouvelles sessions.

TLS 1.3 utilise HKDF (fonction de dérivation de clés fondée sur HMAC) avec un calendrier de clés structuré. Après l’échange de clés ECDHE, le secret partagé alimente une hiérarchie : Extract(early_secret, DHE) -> handshake_secret ; puis Extract(handshake_secret, 0) -> master_secret. À partir de ces secrets, HKDF-Expand-Label dérive des clés distinctes pour le trafic de négociation du client et du serveur, le trafic applicatif et la reprise. Cette séparation nette garantit que la compromission d’une couche de clés n’affecte pas les autres, ce qui constitue une amélioration importante par rapport à la dérivation de clés plus improvisée, fondée sur PRF, de TLS 1.2.

La reprise de session TLS 1.3 utilise des clés prépartagées (PSK) dérivées de sessions précédentes. Après une négociation terminée, le serveur envoie un message NewSessionTicket contenant une identité PSK et une valeur de ticket (un bloc chiffré contenant le secret de reprise). Lors d’une reconnexion, le client inclut l’identité PSK dans ClientHello. Si le serveur la reconnaît, les deux parties dérivent une nouvelle clé de session à partir du PSK et d’un nouvel échange ECDHE, ce qui permet une reprise en 1-RTT avec confidentialité persistante. Le ticket possède une durée de vie configurable, généralement de 24 heures, et devrait être chiffré avec une clé renouvelée régulièrement côté serveur.

TLS 1.3 autorise les données anticipées 0-RTT pour les sessions reprises. Le client utilise le PSK d’une session précédente pour chiffrer les données applicatives envoyées lors de la première volée, avant toute confirmation du serveur. Cela élimine un aller-retour pour les connexions vers des serveurs déjà visités et offre une latence presque nulle lors des reconnexions. Le serveur annonce la prise en charge de 0-RTT dans NewSessionTicket au moyen de l’extension early_data, avec un max_early_data_size. Le serveur doit disposer d’un mécanisme pour accepter ou refuser les données 0-RTT et signale leur acceptation dans EncryptedExtensions.

Les données 0-RTT présentent une limitation fondamentale en matière de sécurité : elles sont vulnérables aux attaques par rejeu. Un attaquant placé sur le chemin qui capture la première volée peut la rejouer auprès du serveur et amener celui-ci à traiter de nouveau les données anticipées. Cette faiblesse est inhérente au mécanisme : le serveur n’a encore envoyé aucun message et n’a donc fourni aucun élément de fraîcheur. Mesures d’atténuation : (1) Tickets à usage unique (le serveur invalide un ticket après sa première utilisation, au moyen d’un cache distribué comme memcached/Redis). (2) Tickets limités dans le temps (refuser les données 0-RTT après une courte fenêtre, par exemple 5 secondes). (3) Idempotence au niveau applicatif (n’autoriser 0-RTT que pour des opérations sûres équivalentes à GET).

Le mécanisme le plus robuste de protection contre le rejeu de 0-RTT repose sur des tickets de session à usage unique. Le serveur conserve un registre des « tickets utilisés » (un cache distribué dans les déploiements comportant plusieurs serveurs). Lorsque des données 0-RTT arrivent, le serveur vérifie si le ticket a déjà été vu : dans l’affirmative, il refuse les données anticipées et revient à une négociation en 1-RTT. Dans le cas contraire, il marque le ticket comme utilisé et traite les données anticipées. Pour garantir la cohérence, tous les serveurs d’une grappe doivent partager le cache des tickets utilisés. Redis avec de courtes durées de conservation, correspondant à la durée de vie des tickets, constitue une implémentation courante. Sans ce mécanisme, 0-RTT est dangereux pour les opérations non idempotentes, comme les paiements.

La reprise TLS 1.3 avec PSK sans DHE n’offre pas de confidentialité persistante pour la session reprise : si le PSK est compromis ultérieurement, tout le trafic de la session reprise peut être déchiffré. Pour maintenir la confidentialité persistante, TLS 1.3 prend en charge PSK-with-DHE : le ClientHello inclut à la fois une identité PSK et un nouveau key_share. Le serveur combine le PSK et le résultat d’ECDHE pour dériver les clés de session. Même si le PSK est compromis, la contribution d’ECDHE garantit que le trafic passé reste protégé. RFC 8446 recommande PSK-with-DHE pour tous les cas de reprise où la confidentialité persistante est requise.

TLS 1.2 comportait plus de 300 combinaisons de suites cryptographiques, dont beaucoup étaient vulnérables. TLS 1.3 réduit ce nombre à 5 suites cryptographiques, qui utilisent toutes AEAD : 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. L’échange de clés et l’authentification sont négociés séparément au moyen des extensions supported_groups et signature_algorithms. Cette séparation élimine la complexité combinatoire de TLS 1.2 et garantit que toute connexion TLS 1.3 utilise un chiffrement authentifié.

En pratique, 0-RTT est surtout utile pour les connexions HTTP/2 où le client répète une requête GET, sûre et idempotente, vers un serveur déjà visité. Les navigateurs utilisent 0-RTT avec prudence : Chrome l’active pour les méthodes HTTP sûres ; les requêtes POST ne sont jamais envoyées comme données 0-RTT. HTTP/3 sur QUIC intègre nativement TLS 1.3 : le 0-RTT de QUIC réutilise le mécanisme de TLS 1.3. Dans QUIC, 0-RTT restaure également les paramètres de transport (contrôle de flux, limites de flux) de la session précédente, ce qui réduit encore le surcoût d’établissement au-delà de la seule couche TLS.

TLS 1.3 intègre des mécanismes destinés à empêcher les attaques par rétrogradation de version. Le champ aléatoire de ServerHello contient une valeur sentinelle lorsque TLS 1.3 est négocié : ses 8 derniers octets prennent une valeur fixe (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 pour le repli vers TLS 1.2). Les clients compatibles avec TLS 1.3 vérifient cette valeur sentinelle lorsque le serveur négocie TLS 1.2, ce qui permet de détecter les tentatives actives de rétrogradation. De plus, le hachage de la transcription du message de fin couvre toute la négociation, y compris la négociation de version, de sorte que toute altération peut être détectée. SCSV (valeurs de signalisation des suites cryptographiques), comme TLS_FALLBACK_SCSV, fournit un signal distinct de rétrogradation pour les versions plus anciennes de TLS.

Le déploiement de TLS 1.3 nécessite de prêter attention à plusieurs aspects opérationnels. Les clés de chiffrement des tickets de session doivent être renouvelées, généralement toutes les 24 heures, et synchronisées entre les grappes de serveurs afin de permettre une reprise sur n’importe quel serveur. Les anciennes clés de déchiffrement des tickets doivent être conservées pendant toute la durée de vie des tickets pour éviter les échecs intempestifs de négociation. L’agrafage OCSP est plus important avec TLS 1.3, car il faut un aller-retour de moins pour vérifier l’état du certificat. Les équilibreurs de charge doivent transmettre ClientHello de TLS 1.3 sans modification : certains équipements intermédiaires anciens altèrent les extensions inconnues, ce qui nécessite des modes de compatibilité.

Pourquoi les données anticipées 0-RTT sont-elles vulnérables aux attaques par rejeu dans TLS 1.3 ?

TLS 1.3 permet des négociations complètes en 1-RTT et une reprise en 0-RTT grâce aux tickets de session PSK. La dérivation des clés utilise HKDF avec un calendrier structuré qui produit des clés distinctes pour chaque couche de trafic. Les données anticipées 0-RTT éliminent un aller-retour, mais sont vulnérables au rejeu : ce risque est atténué par les tickets à usage unique et par la limitation de 0-RTT aux opérations idempotentes. PSK-with-DHE préserve la confidentialité persistante lors de la reprise. TLS 1.3 limite les suites cryptographiques à 5 options AEAD, éliminant les combinaisons héritées vulnérables. La prévention des rétrogradations utilise des valeurs sentinelles dans le champ aléatoire du serveur.