Résumé

  • ECH place le véritable SNI et d’autres paramètres sensibles dans un ClientHelloInner chiffré, transporté par un ClientHelloOuter public.
  • La confidentialité dépend d’une chaîne : publication DNS d’une configuration fraîche, clé disponible sur le serveur frontal, reprise cohérente et comportements publics assez semblables.
  • ECH ne masque ni l’adresse IP, ni la question au résolveur, ni toute corrélation de trafic ; la présence d’un paramètre ech ne prouve pas que la négociation a abouti.

La clé arrive par un canal antérieur à TLS

Le paradoxe d’ECH tient dans l’ordre des opérations. Le client veut cacher le nom au premier message TLS, mais il lui faut déjà une clé publique et le nom de la porte d’entrée. Cette instruction arrive normalement par le DNS. La confidentialité de la poignée de main commence donc avant la poignée de main.

L’extension server_name de RFC 6066 permettait au client de choisir un service parmi plusieurs hôtes virtuels. Comme ClientHello ouvre la négociation définie par RFC 8446, ce choix restait lisible sur le trajet, même si TLS 1.3 chiffrait ensuite l’essentiel de l’échange.

RFC 9849, publié en mars 2026 sur la voie Standards Track, remplace cette présentation unique par deux messages liés. Le client compose un message interne avec le vrai nom et, éventuellement, la liste ALPN. Il le chiffre avec HPKE au moyen d’une clé issue d’un ECHConfig. Le message externe contient un nom public et l’extension qui transporte le bloc interne scellé.

Si la porte accepte ECH, elle traite ou transmet le message interne. Si elle ne peut pas l’ouvrir, elle poursuit avec l’externe et peut retourner une configuration à jour. Le client vérifie l’acceptation. Une connexion où ECH a été proposé puis refusé ne sert pas aux données applicatives : le refus ouvre une reprise, pas une rétrogradation silencieuse.

Une porte partagée, deux rôles possibles

En mode partagé, le serveur visible et le terminateur TLS ne forment qu’un système. En mode séparé, le serveur frontal ouvre le message interne puis le remet à un serveur d’origine qui termine TLS. La porte connaît alors la destination nécessaire au routage, sans devenir pour autant le terminateur du flux applicatif protégé.

Ce découpage distribue les responsabilités. Le propriétaire DNS publie la configuration. Le client décide de l’utiliser. La porte détient la clé privée correspondante. L’origine confirme l’acceptation dans la transcription TLS. La confidentialité est le résultat de cet accord ; aucune simple case « activé » ne le remplace.

La configuration comprend aussi un identifiant, des suites HPKE, un nom public et une longueur utile au bourrage. La porte doit conserver les clés actuelles et celles que des caches peuvent encore présenter. Une rotation trop lente prolonge l’exposition d’une clé compromise ; une rotation trop rapide multiplie les reprises et fragmente l’ensemble d’anonymat. Les RFC décrivent cette tension sans imposer un délai universel.

Le DNS publie la promesse et peut aussi révéler son absence

RFC 9848 définit le paramètre ech dans les enregistrements de liaison de service de RFC 9460. SVCB et HTTPS peuvent annoncer des points de terminaison et leurs paramètres avant la connexion. ECH y place sa configuration.

Un RRSet mêlant des destinations avec et sans ECH ouvre une rétrogradation par blocage : l’intermédiaire rend les destinations protégées injoignables et laisse l’alternative claire. RFC 9848 déconseille cette combinaison. Plus largement, empêcher la résolution SVCB peut priver le client de la connaissance même de la politique ECH.

Le transport chiffré vers le résolveur limite l’observation locale ; il ne rend pas le résolveur aveugle. L’adresse de destination reste également visible. ECH retire un nom explicite du ClientHello, il n’efface pas l’environnement qui entoure la connexion.

L’ensemble d’anonymat doit exister en exploitation

La propriété recherchée n’est pas « personne ne sait rien », mais l’indistinguabilité entre plusieurs noms servis par une même porte. Si chaque nom reçoit son propre identifiant ou sa propre clé, l’ensemble peut se réduire à une unité. Il se réduit aussi si un serveur expose une suite cryptographique, un ordre d’extensions, une taille de cookie ou un rythme de reprise qui le distingue.

Le chiffrement protège le contenu interne ; l’exploitation dessine la silhouette externe. Une grande plateforme peut regrouper de nombreux noms, mais elle doit aussi aligner leur comportement public. À l’inverse, une configuration techniquement valide pour un seul nom peut protéger le texte du SNI sans fournir la foule annoncée par le modèle de confidentialité.

Les erreurs doivent rester observables

GREASE ECH envoie une extension vraisemblable même lorsqu’aucune configuration réelle n’est utilisée. Il révèle les équipements intermédiaires intolérants et évite que le vrai ECH soit la seule forme inhabituelle. En contrepartie, un échec de déchiffrement isolé ne prouve pas une panne : il peut s’agir de GREASE.

Les opérateurs disposent de signaux plus précis : configurations de reprise, boucles entre grappes et alerte ech_required. Une seconde reprise incompatible indique davantage un déploiement divergent qu’un premier essai impossible à ouvrir.

Ce que les documents ne permettent pas d’affirmer

Les cinq RFC fixent les formats, les rôles et les propriétés visées. Ils ne donnent pas le taux mondial de déploiement, l’état d’un navigateur ou d’un réseau, ni la taille réelle de l’ensemble d’un fournisseur. Ils ne prouvent pas davantage que le DNS est chiffré ou validé sur le trajet d’un lecteur.

Sources