Résumé

  • En TLS 1.3, HelloRetryRequest ne recommence pas la négociation. Le second ClientHello doit reproduire le premier, hormis une liste étroite de changements autorisés : nouvelle part de clé demandée, retrait des données anticipées, retour d’un cookie et recalcul des binders.
  • Le protocole remplace les octets de ClientHello1 par un message synthétique message_hash contenant son condensat, puis authentifie cet engagement avec la relance et la suite de l’échange. L’absence d’état compresse l’histoire sans la supprimer.
  • La preuve opérationnelle doit conserver les deux ClientHello, le motif de relance, l’écart permis, la politique de cookie, le groupe final, les alertes et la latence ajoutée. Une connexion réussie ne prouve ni la validité de la relance ni une préférence initiale du client.

Une capture qui commence trop tard

Le diagnostic semblait simple. Le second ClientHello envoyait une seule part de clé. ServerHello retenait le même groupe, puis CertificateVerify et Finished réussissaient. Le tableau de bord résumait donc l’événement ainsi : le client a proposé ce groupe, le serveur l’a accepté.

Le premier message manquant racontait une autre séquence. Le client avait annoncé plusieurs groupes dans supported_groups, mais n’avait calculé une part immédiate que pour un autre groupe. Le serveur avait refusé cette prédiction et envoyé HelloRetryRequest pour demander un groupe déjà déclaré compatible, sans part correspondante dans le premier vol. La part unique du second Hello était la réponse à une décision du serveur, pas la preuve du choix originel du client.

Il faut séparer ce que la configuration autorisait, ce que le client déclarait compatible, ce qu’il avait prédit en envoyant une part, ce que le serveur demandait et ce qui fut finalement négocié. Une observabilité limitée au second vol attribue au client la préférence du serveur, dissimule le tour de réseau supplémentaire et fausse l’analyse d’une migration cryptographique.

Une relance régie par une liste fermée

La spécification TLS 1.3 actuelle impose que ClientHello2 reste identique à ClientHello1, sauf exceptions explicites. Une extension key_share dans la relance remplace les anciennes parts par une seule part neuve pour le groupe indiqué. early_data doit disparaître. Un cookie reçu doit être recopié. Les binders PSK sont recalculés sur la trace qui inclut la relance. Une future extension ne pourra autoriser un autre écart que si elle est présente et en définit précisément la règle.

Il ne s’agit pas d’une ressemblance approximative. C’est une liste d’autorisation. Le protocole protège autant la frontière des champs modifiables que le groupe finalement retenu.

Le groupe demandé doit avoir figuré dans le supported_groups initial et ne doit pas avoir déjà bénéficié d’une part dans le premier key_share. Une relance sans changement utile, une deuxième relance, une suite cryptographique jamais offerte ou un ServerHello incompatible avec le groupe demandé doivent provoquer un rejet.

Le mot courant « retry » devient ainsi une transition déterministe. Le serveur peut demander une correction utile, une seule fois. Il ne peut ni rouvrir tous les paramètres ni répéter la demande jusqu’à imposer une autre politique.

message_hash préserve l’offre initiale

Les calculs cryptographiques de TLS dépendent d’un condensat ordonné des messages de négociation. Un serveur qui veut émettre un cookie puis abandonner son état par client ne souhaite pas conserver chaque ClientHello complet ni exporter un état de hachage propre à son implémentation.

TLS remplace alors ClientHello1 dans la trace par un message synthétique de type 254, message_hash, dont le corps vaut Hash(ClientHello1). La trace se poursuit avec HelloRetryRequest, ClientHello2, ServerHello et les messages d’authentification. CertificateVerify, Finished et le binder PSK calculé après relance restent donc liés à la première proposition.

Ce mécanisme est un engagement, pas une archive réversible. Les deux extrémités peuvent détecter une rupture cryptographique de l’histoire, mais un opérateur ne peut pas retrouver les extensions et les parts initiales à partir du seul condensat. La preuve protocolaire assure la continuité ; une capture ou un relevé structuré explique l’écart.

Compatibilité, prédiction et sélection ne sont pas synonymes

Le client TLS 1.3 tente d’économiser un aller-retour en prédisant des parts de clé dans son premier message. Produire une part pour chaque groupe compatible augmente le calcul et la taille du ClientHello. N’en produire qu’une réduit les octets, mais expose à une relance si le serveur exige un autre groupe compatible.

Les groupes hybrides post-quantiques rendent l’arbitrage plus visible. OpenSSL expose des ensembles de groupes, des parts prédites et la préférence du serveur. Sa documentation souligne aussi qu’un grand ClientHello peut franchir une limite de segment TCP et rencontrer un pare-feu défectueux, tandis qu’une part différée réserve l’aller-retour supplémentaire aux serveurs qui la réclament réellement. GnuTLS sépare lui aussi la politique de groupes de l’option qui envoie une seule part TLS 1.3.

Une ligne d’inventaire disant « groupe X pris en charge » ne suffit donc pas. L’implémentation peut connaître X, la configuration peut l’activer, le premier message peut l’annoncer sans envoyer sa part, le serveur peut ensuite le demander et la connexion peut enfin le sélectionner. Chacun de ces états appelle une preuve distincte.

Les données anticipées ne passent pas par ce détour

Si le premier ClientHello contenait early_data, le second le retire. HelloRetryRequest prouve donc que le serveur n’a pas accepté le chemin 0-RTT de cette négociation.

Le client a pourtant pu envoyer des octets applicatifs avant de recevoir la relance. L’application reste responsable de décider si une opération peut être répétée, si une réponse a déjà été observée et comment réconcilier un effet de bord. Le succès ultérieur en 1-RTT ne rend pas automatiquement une action idempotente.

La télémétrie doit distinguer la tentative, le refus par relance, la décision de retransmission et le résultat métier. Une simple étiquette « session reprise avec succès » efface la transition la plus importante.

Un cookie ne prouve que ce qu’il encode

Le serveur peut placer un cookie opaque dans HelloRetryRequest et exiger son retour inchangé. Il peut y engager le condensat du premier Hello, les paramètres retenus, une heure ou un contexte de routage. Une protection d’intégrité établit que le jeton provient du détenteur de la clé et n’a pas été modifié, dans les limites de la conservation des clés, de sa durée et des règles de validation.

DTLS 1.3 offre un cas différent : lier le cookie à l’adresse apparente afin de vérifier le chemin retour avant une réponse amplifiée. La rotation des secrets, les périodes de chevauchement et les horodatages montrent qu’un jeton sans état possède malgré tout un cycle de vie.

La joignabilité n’est pas une identité. Le retour d’un cookie peut établir que quelqu’un recevait les paquets à cette adresse pendant une période donnée. Il n’identifie ni une personne ni un rôle de machine, et ne confère aucune permission applicative. Un cookie valide ne dispense jamais de comparer les deux ClientHello.

Toute extension doit rejoindre la même histoire

Encrypted Client Hello fournit un exemple circonscrit. La valeur random de HelloRetryRequest étant fixe, ECH ne peut pas y inscrire sa confirmation comme dans un ServerHello ordinaire. Il définit donc une extension encrypted_client_hello dont la confirmation est dérivée du ClientHello interne et de la relance modifiée.

L’enseignement n’est pas de transformer cette étude en guide ECH. Il est qu’une extension doit définir ce qui peut changer, où apparaît son signal et comment il rejoint l’historique authentifié. Elle ne reçoit pas le pouvoir d’ouvrir une négociation parallèle.

Une preuve utilisable après l’incident

Un relevé solide commence avant ce que de nombreux outils appellent la connexion. Il conserve le condensat et, si la politique le permet, les champs analysés de ClientHello1 ; le HelloRetryRequest exact ; un condensat du cookie plutôt que son secret ; les champs de ClientHello2 ; et le ServerHello final. Chaque décision est reliée à une version d’implémentation et de configuration.

Pour les groupes, il faut enregistrer l’ensemble activé, l’ordre annoncé, les parts prédites, la préférence serveur, le groupe demandé, la part retournée et le groupe négocié. Pour la relance : motif, conformité de l’écart, alerte de rejet et éventuelle deuxième demande. Pour l’effet : RTT ajouté, tailles des deux Hello, fragmentation, sort des données anticipées, achèvement et population de clients.

La preuve négative compte aussi. Tester le rejet d’un groupe absent de la liste initiale, d’un groupe déjà partagé, d’une relance sans changement, d’une suite modifiée, d’une seconde relance et d’un ServerHello incohérent. Le banc BoringSSL modélise ces variantes parce qu’un rejet correct fait partie de l’interopérabilité.

La connexion terminée est la fin du récit, pas la preuve que toutes les décisions antérieures étaient légitimes. Cette preuve réside dans la chaîne des changements autorisés.

Sources