Le 0-RTT : Zero Round-Trip Time
Réseau
0-RTT : Zero Round-Trip Time. « zéro aller-retour » : un client qui a déjà parlé à un serveur envoie ses premières données chiffrées dès son premier message, sans attendre la fin de la poignée de main, comme un habitué qui commande au comptoir avant même d'avoir dit bonjour. Le mécanisme existe dans TLS 1.3 (RFC 8446) et dans QUIC (RFC 9001).
Prérequis : Il faut une session antérieure : le serveur a remis au client un ticket de reprise associé à une clé prépartagée (PSK) et a annoncé, via l'extension early_data, la taille maximale de données précoces acceptée. Sans ce ticket, la connexion revient au cas normal à un aller-retour.
Rejeu : Les données précoces ne sont pas protégées contre le rejeu : un attaquant qui les capture peut les renvoyer au serveur. On gagne un aller-retour, on offre une rediffusion ; d'où la règle de n'y placer que des requêtes idempotentes, et le code HTTP 425 Too Early de la RFC 8470 pour les refuser.
Confidentialité persistante : Les clés des données précoces dérivent uniquement de la PSK, sans nouvel échange Diffie-Hellman. Si cette clé est compromise, ces données sont déchiffrables, alors que le reste de la session reste protégé si un échange (EC)DHE a été mené.
Refus possible : Le serveur peut ignorer les données précoces ; le client doit alors les renvoyer après la poignée de main complète. Le 0-RTT reste donc une optimisation, jamais une garantie.
Ce qui arrive si on s'en passe
Le 0-RTT est une optimisation de latence, pas une protection : le laisser désactivé n'ouvre aucune possibilité à un attaquant. La conséquence est un aller-retour réseau supplémentaire à chaque reprise de session avant le premier octet utile, ce qui se ressent surtout sur les liaisons à forte latence, comme le mobile ou l'intercontinental. À l'inverse, l'activer introduit un risque réel : les données précoces peuvent être rejouées et ne bénéficient pas de la confidentialité persistante. Si on l'active, il faut le limiter aux requêtes sans effet de bord, comme un GET idempotent, mettre en place une protection anti-rejeu côté serveur, et renvoyer 425 Too Early pour tout le reste.
Explication de la marmotte
Avant de discuter en secret sur Internet, deux ordinateurs échangent d'abord quelques messages pour se mettre d'accord sur un code commun. Cet échange prend du temps, car chaque message doit faire l'aller et le retour. Quand un ordinateur revient vers un site qu'il connaît déjà, il peut réutiliser un code gardé de la visite précédente et envoyer sa demande tout de suite, dans le tout premier message. On gagne du temps. Le revers est qu'une personne mal intentionnée peut recopier ce premier message et le renvoyer, un peu comme une photocopie d'un bon de commande. Il faut donc n'y mettre que des demandes sans danger si elles sont répétées.
Où ce terme est utilisé
- La poignée de main TLS 1.3 en une page (3 occurrences)
- Sécuriser un canal: TLS, HTTPS et mTLS (3 occurrences)
- DNS over TLS (DoT) : chiffrer la résolution de noms (1 occurrence)