Résumé

  • Le 0-RTT de TLS 1.3 réduit la latence d’une reprise de connexion, mais ne fournit pas à lui seul une protection contre le rejeu des données précoces.
  • Une décision défendable relie l’acceptation du transport à la sémantique de la requête, à l’idempotence applicative, à l’autorisation actuelle et à l’effet réellement validé.

Imaginons un service de paiement qui autorise un client connu à reprendre une session TLS et à envoyer immédiatement un ordre de virement. Un premier point de présence déchiffre la requête et la transmet avant la fin de la nouvelle poignée de main. Une copie rejouée atteint un second point de présence pendant la fenêtre d’acceptation du ticket. Les deux sites consignent des données précoces valides ; le grand livre reçoit deux ordres. Le transport a tenu sa promesse. L’application lui en a attribué une autre.

Un aller-retour économisé a un coût défini

La RFC 8446 autorise un client qui reprend une connexion au moyen d’une clé prépartagée à envoyer des données applicatives en 0-RTT avant l’achèvement d’une nouvelle poignée de main. Pour une lecture tolérant la répétition, cette faculté peut améliorer nettement la première interaction.

La frontière de sécurité est explicite : TLS n’offre pas de protection intrinsèque contre le rejeu des données 0-RTT. Un adversaire qui enregistre le premier vol peut rejouer le ClientHello et les données associées. Le serveur peut néanmoins authentifier le contexte de reprise et déchiffrer correctement les octets. L’acceptation cryptographique prouve donc leur compatibilité avec un contexte de données précoces accepté, pas une livraison ni une exécution unique.

La télémétrie masque facilement cette différence. Un tableau de bord peut afficher un ticket valide, une acceptation 0-RTT et une réponse applicative réussie. Aucun de ces indicateurs ne dit si la même commande a atteint un autre processus, une autre région ou un chemin de nouvelle tentative. Un événement TLS vert est plus étroit qu’un résultat métier « exactement une fois ».

L’anti-rejeu est une discipline opérationnelle, pas une case cochée

La RFC 8446 décrit plusieurs moyens de réduire l’exposition : tickets à usage unique, mémorisation des ClientHello ou contrôles de fraîcheur fondés sur l’âge du ticket et l’heure d’arrivée observée. Chaque option dépend d’un état opérationnel. Un ticket à usage unique exige que la décision d’acceptation ne soit ni perdue ni divergente. L’enregistrement des ClientHello suppose une base de rejeu disponible et bornée. Les contrôles de fraîcheur reposent sur des horloges, des tolérances et une fenêtre de risque assumée.

Dans un réseau périphérique distribué, le problème devient collectif. Si deux sites peuvent accepter le même matériel de reprise sans partager une décision d’usage unique, le résultat local « jamais vu » n’est pas une preuve globale. Si le mode de secours choisit l’acceptation lorsque l’état anti-rejeu est indisponible, la politique de disponibilité élargit la surface d’exécution. Ce compromis peut être légitime, mais il doit être visible.

Refuser les données précoces ne dispense pas non plus l’application de suivre l’effet. Le client peut recommencer après la poignée de main. Si la première tentative avait franchi une frontière applicative avant que le rejet ne soit observé, la nouvelle tentative peut reproduire l’action. La preuve doit suivre la requête à travers acceptation, rejet, transmission, nouvelle tentative et validation finale.

HTTP rend visible la décision manquante

La RFC 8470 décrit l’usage des données précoces par HTTP et répartit les responsabilités entre client, intermédiaire et serveur d’origine. Un client ne devrait pas placer sans précaution une opération dangereuse dans les données précoces. Un intermédiaire doit préserver le fait que la requête est arrivée tôt. Un serveur qui refuse le risque peut répondre 425 Too Early, afin que le client réessaie hors 0-RTT.

Ce code constitue un transfert de contrôle, non une déclaration selon laquelle toute requête acceptée serait inoffensive. Le nom de la méthode ne suffit pas non plus. Une lecture apparemment sûre peut déclencher une facturation, consommer une ressource rare ou produire un effet d’audit. Une écriture dite idempotente cesse de l’être si sa clé manque ou si sa portée diffère entre régions. La résistance au rejeu appartient à l’opération telle qu’elle est réellement exécutée.

QUIC matérialise la même frontière. La RFC 9001 intègre les données précoces TLS à QUIC ; le serveur peut rejeter le 0-RTT et le client doit traiter ce résultat. Le chemin de renvoi fait donc partie du graphe d’exécution applicatif. Compter les seuls paquets QUIC acceptés ne permet pas de démontrer que la commande métier n’a été appliquée qu’une fois.

Construire un reçu de décision sur les données précoces

L’objet de preuve durable est un reçu de décision. Il relie l’empreinte et l’âge du ticket de reprise, la référence de poignée de main, le point de présence, le mécanisme anti-rejeu, la fenêtre applicable, l’empreinte de la requête, sa méthode et sa classe d’effet, la clé d’idempotence, le principal et l’époque de politique d’autorisation, le résultat de transmission, les nouvelles tentatives, l’effet validé et les horodatages.

Ce reçu doit aussi conserver l’incertitude. Une observation unique sur un site ne prouve pas l’unicité à l’échelle du réseau. Un ticket valable ne démontre pas une autorisation métier actuelle. Une empreinte de requête ne garantit pas une sémantique identique si des en-têtes cachés, l’état du compte ou la portée régionale ont changé. Un rejet de transport ne prouve pas qu’aucun composant en aval n’a vu la première tentative.

Cette séparation rend le choix de performance gouvernable. Une équipe peut autoriser le 0-RTT pour les opérations dont la répétition est sans conséquence, exiger une clé d’idempotence appliquée globalement pour certaines écritures, ou refuser les données précoces lorsque l’autorisation et les effets irréversibles ne peuvent être tranchés avec sûreté. Le bon indicateur n’est pas la proportion de poignées de main accélérées, mais la proportion d’opérations précoces dont l’historique d’exécution reste explicable.

Sources