Résumé

  • Le 0-RTT de TLS 1.3 permet à un client déjà connu d’envoyer des données avec son ClientHello. Il économise une ou deux traversées du réseau, mais ne garantit pas que ces données ne seront pas rejouées sur une autre connexion.
  • Le RFC 8470 place la décision au bon niveau : l’origine connaît les conséquences de la ressource, les intermédiaires conservent la provenance Early-Data: 1, et le code 425 refuse une requête particulière sans condamner toute l’optimisation.
  • Le client peut réessayer automatiquement, à condition que la nouvelle transmission ne soit plus une donnée précoce. La cible et l’opération peuvent rester identiques ; c’est leur contexte cryptographique qui change.

Le gain de temps créait une dette de preuve

Dans une connexion TLS ordinaire, la requête HTTP attend que le client et le serveur aient échangé leurs messages de négociation. Cette attente ne transporte pas seulement des octets cérémoniels. Elle fait dépendre les clés applicatives d’un état neuf produit par les deux côtés.

TLS 1.3 a offert un raccourci à un client qui possède un ticket et une clé de reprise issus d’une session antérieure. Il peut joindre des données applicatives à son ClientHello, avant de recevoir le nouveau ServerHello. Pour HTTP, cela peut supprimer une ou deux latences aller-retour.

Le RFC 8446 borne clairement ce privilège. Les données 0-RTT sont chiffrées, mais elles ne bénéficient pas de confidentialité persistante et ne possèdent aucune garantie de non-rejeu entre connexions. Elles sont parties avant que l’aléa du nouveau serveur puisse les distinguer d’une copie présentée ailleurs.

La faiblesse est précise. L’attaquant ne peut ni modifier librement le message authentifié, ni le convertir en données 1-RTT, ni le dupliquer deux fois dans la même connexion. Il peut tenter de reproduire le vol précoce sur une autre connexion qui accepte encore le même contexte de reprise.

Un rejeu n’est pas un nouvel essai

Le client réessaie lorsqu’une réponse se perd ou qu’une connexion casse. Il sait alors qu’il prend une nouvelle décision. Le rejeu décrit par le protocole est une copie déclenchée hors de sa connaissance. Ces événements restent distincts, mais une infrastructure distribuée peut les faire se rencontrer.

Une copie peut atteindre une première zone, y être acceptée et produire un effet. Une seconde zone, faute d’un état de rejeu identique, peut refuser le 0-RTT tout en terminant la négociation. Si la réponse de la première zone est masquée, le client peut légitimement renvoyer l’opération sur la seconde. Un même achat ou une même consommation de jeton apparaît alors deux fois, l’une par rejeu et l’autre par récupération normale.

TLS propose des tickets à usage unique, un journal des ClientHello récents, des fenêtres de fraîcheur et des zones faisant autorité pour un ticket. Ces mécanismes réduisent l’espace du rejeu, mais ils demandent une cohérence difficile entre machines, régions et redémarrages. Surtout, ils ignorent le sens métier du message.

Le verbe HTTP ne suffisait pas

Il serait tentant de décider avec la seule méthode. GET et HEAD sont définies comme sûres ; PUT et DELETE sont idempotentes ; POST annonce souvent un changement. Cette grammaire reste utile pour le client, mais elle ne décrit pas toutes les conséquences d’une ressource.

Un GET peut consommer une URL signée, déclencher un calcul facturé, chauffer un cache ou inscrire un événement durable. Un appel conçu avec une clé de transaction peut, à l’inverse, tolérer une répétition que son verbe ne laisse pas deviner. Le RFC 8470 refuse donc de transformer la sécurité théorique de la méthode en certificat universel de tolérance au rejeu.

Le client sait ce qu’il tente d’envoyer tôt. TLS sait dans quelle phase les octets sont arrivés. La passerelle sait où les acheminer. Seule l’origine connaît normalement les effets précis de la ressource. Le profil HTTP devait rendre ce dernier savoir exécutable.

Trois refus, trois granularités

L’origine dispose de trois stratégies conformes. Elle peut refuser tout le vol précoce au niveau TLS. C’est robuste, mais TLS ne peut pas accepter une requête 0-RTT et en éliminer une autre dans le même ensemble.

Elle peut aussi différer le traitement HTTP. Le serveur lit juste assez pour choisir une politique, puis attend la fin de la poignée de main avant tout effet. Sur une connexion multiplexée, plusieurs requêtes peuvent ainsi recevoir des traitements temporels différents.

Enfin, elle peut répondre 425 Too Early à la seule requête qu’elle ne veut pas risquer. Ce choix renvoie la décision au client et permet aux autres ressources explicitement tolérantes de conserver l’avantage du 0-RTT. La vitesse devient un droit conditionnel par ressource, non un interrupteur pour tout le site.

La provenance devait traverser les relais

Le code qui comprend la ressource ne termine pas toujours la connexion du lecteur. Un CDN, un mandataire inverse et une passerelle peuvent se trouver entre les deux. L’origine peut donc recevoir une requête sur une connexion parfaitement établie alors que le premier relais l’avait reçue trop tôt.

Le champ Early-Data porte cette histoire avec l’unique valeur valide 1. Un intermédiaire qui transmet avant l’achèvement de sa négociation côté client doit l’ajouter. Celui qui le reçoit ne doit pas le supprimer. Une copie déjà marquée reste marquée même si le prochain tronçon attend son propre handshake.

Ce bit ne demande pas d’aller vite. Il atteste qu’un tronçon amont a pu voir ou transmettre la requête pendant une fenêtre rejouable. Attendre plus loin ne répare pas un risque déjà créé plus haut. Les occurrences multiples ou invalides sont ramenées au même fait conservateur, afin qu’une ambiguïté syntaxique ne blanchisse pas l’historique.

425 renvoie l’intention dans un autre temps

Après un 425 reçu pour des données précoces, l’agent utilisateur devrait réessayer automatiquement. La règle essentielle est négative : le nouvel essai ne doit pas être envoyé en early data. Le client attend l’état applicatif ordinaire, puis retransmet.

La méthode, la cible, le corps et l’intention peuvent rester les mêmes. Ce n’est pas une redirection vers un autre objet, ni un jugement sur la validité du certificat. L’origine correcte peut être en parfaite santé. Elle refuse seulement de laisser ce contexte particulier autoriser des effets.

Le code ne signifie ni limite de débit comme 429, ni indisponibilité comme 503, ni mauvaise autorité de connexion comme 421. Il ne joue pas non plus le rôle de 100 Continue, qui coordonne l’envoi du corps. Le 425 est une réponse finale à une preuve temporelle insuffisante et n’est pas stockable par défaut. Le registre IANA conserve ce sens étroit.

Un serveur ne devrait l’émettre que si la requête est arrivée comme donnée précoce ou porte Early-Data: 1. Sans ce signal, rien ne prouve que le client connaît le mécanisme de récupération particulier.

L’intermédiaire ne peut réparer que le risque qu’il vient de créer

Tout intermédiaire peut transmettre la réponse. Lorsque la requête était déjà marquée, il doit transmettre le 425 : le risque précède sa connexion actuelle.

Une exception locale existe lorsque l’intermédiaire a lui-même reçu des données précoces non encore marquées. Il peut absorber le 425 de l’origine, attendre la fin du handshake avec le client, puis réessayer en aval. Il connaît alors l’endroit exact où commence l’historique et peut réellement changer son temps.

Une passerelle ne doit pas envoyer tôt vers une origine qui ne comprend pas le champ et ne sait pas produire 425. Sinon, l’infrastructure accepte au nom de l’application un risque que celle-ci ne peut ni voir ni refuser. Elle doit attendre ou retourner elle-même le refus.

Ce qui compte est le début de l’effet

Une requête peut franchir la limite de négociation : ses en-têtes arrivent tôt, son corps plus tard. Avec QUIC, un flux qualifié de précoce peut même être livré après la fin du handshake. L’heure du dernier paquet ne suffit donc pas.

La question est : quand l’instance commence-t-elle à agir ? Lire des en-têtes ou choisir une route peut être neutre. Écrire, appeler un système externe, consommer un droit ou publier un message ne l’est pas. Toutes les instances capables d’accepter le même ticket doivent partager l’invariant « aucun effet trop tôt », même si l’une rejette TLS, l’autre attend et la troisième répond 425.

Un serveur fraîchement redémarré ne possède pas l’historique de rejeu antérieur. Tant que sa fenêtre d’enregistrement chevauche cet aveuglement, il doit refuser le 0-RTT. La disponibilité d’un raccourci ne peut pas reposer sur l’oubli local.

HTTP/3 a conservé le contrat

Le passage de TCP à QUIC n’a pas supprimé le problème. Le RFC 9114 applique les protections du RFC 8470 au 0-RTT de HTTP/3.

HTTP/3 ajoute une autre preuve : le client envoie tôt en se fondant sur les SETTINGS mémorisés de la session précédente. Le serveur doit refuser le 0-RTT s’il ne peut pas établir leur compatibilité avec ses paramètres actuels. Une fois qu’il accepte, il ne peut annoncer ensuite des limites réduites que les données déjà envoyées auraient violées.

La compatibilité des SETTINGS et la tolérance de la ressource sont deux contrôles séparés. L’un protège l’état du protocole, l’autre les conséquences de l’action. Leur coexistence montre ce que l’attente traditionnelle fournissait sans le nommer.

Sources et limites de preuve

Le dossier fermé comprend TLS 1.3, RFC 8446, Using Early Data in HTTP, RFC 8470, HTTP/3, RFC 9114 et le registre IANA des codes HTTP, qui enregistre 425 comme Too Early. Ces textes prouvent la conception et ses limites, pas la fréquence actuelle d’usage, le support universel des clients, un incident nommé, un gain mesuré pour un service ni une exécution exactement une fois.