Résumé

  • ECH transforme l'enregistrement HTTPS/SVCB en configuration cryptographique active: la clé publiée n'est utile que si le point de terminaison possède la clé privée correspondante.
  • La mesure décisive est la fenêtre de désaccord entre première visibilité DNS et disponibilité de la clé dans toute la flotte, non la présence d'un bouton « ECH activé ».
  • Les configurations de retry réparent un décalage borné; un retry persistant ou répété révèle une divergence entre versions DNS, cohortes edge ou backends.
  • Les plateformes intégrées peuvent mutualiser chevauchement, garde des clés et télémétrie. La portabilité dépend de reçus de version exportables.

Un enregistrement DNS qui engage la terminaison TLS

RFC 9849 sépare un ClientHelloInner privé d'un ClientHelloOuter visible. Le premier contient le vrai nom de serveur et les préférences sensibles; le second transporte l'enveloppe chiffrée. Le serveur en façade ne peut ouvrir cette enveloppe qu'avec la clé privée correspondant à l'ECHConfig obtenue par le client.

RFC 9848 décrit la publication du paramètre ech dans les liaisons de service DNS. RFC 9460 définit SVCB et HTTPS comme des ensembles liés d'instructions de connexion. Le DNS ne se contente donc plus d'indiquer une adresse: il distribue la moitié publique d'une configuration qui détermine la forme du premier message TLS.

L'ordre devient un choix économique. Activer la clé partout avant publication impose une période de chevauchement. Publier d'abord expose les clients au dernier nœud non prêt. Le certificat peut rester valide et le HTTPS ordinaire fonctionner. Ce qui manque est précisément le résultat recherché: une acceptation ECH dès la première connexion.

Quatre plans de contrôle pour une seule tentative

Le navigateur décide d'offrir ECH. La politique Chrome Enterprise précise que l'usage dépend encore du support serveur, de la disponibilité de l'enregistrement HTTPS et du déploiement. La FAQ de Firefox documente l'activation par défaut depuis Firefox 119, mais aussi les chemins de désactivation d'entreprise, de contrôle parental et de middlebox approuvée.

Le résolveur décide ce que le navigateur apprend. RFC 9460 rappelle que la suppression d'une réponse SVCB peut supprimer le bénéfice associé. La documentation Cloudflare décrit la suppression des réponses HTTPS et le domaine canari comme contrôles locaux, tout en signalant le risque d'une réécriture incompatible avec la validation DNSSEC.

Le DNS faisant autorité choisit la version, le TTL et la chaîne d'alias. La flotte edge choisit où la clé privée est chargée et quand l'ancienne disparaît. Une rotation vérifiable doit relier le hash d'ECHConfigList, les identifiants de configuration, la première observation DNS, l'état de chaque cohorte, le résultat d'acceptation, le retry et la traîne des caches.

Le retry n'efface pas l'incident initial

ECH permet au serveur de renvoyer une configuration de retry. C'est un mécanisme utile: un client muni d'une ancienne clé peut établir une nouvelle connexion avec une configuration corrigée. Mais le succès de cette seconde connexion ne rend pas atomique la première publication. Il prouve qu'une incompatibilité a été réparée, avec une connexion et une latence supplémentaires.

RFC 9849 recommande de ne pas accepter une nouvelle configuration de retry en réponse à une connexion déjà issue d'un retry. Le texte cite des configurations serveur multiples et incohérentes comme cause possible. Une correction qui en appelle une autre n'est plus un protocole de récupération; c'est un inventaire qui ne sait pas quelle version fait autorité.

Il faut donc compter les retries par version, résolveur, famille cliente et cohorte edge. Une courte traîne pendant une rotation peut être maîtrisée. Une concentration durable sur un site est un incident de configuration. Un taux agrégé masque précisément la frontière que l'opérateur doit trouver.

L'ensemble d'anonymat a lui aussi une configuration

ECH protège le SNI et d'autres champs, mais son objectif de confidentialité dépend de services extérieurement semblables. Des différences de cookie HelloRetryRequest, de nom de clé, d'ordre d'extensions ou de réaction d'erreur pourraient distinguer un backend malgré le chiffrement du ClientHelloInner. Les normes décrivent ce mécanisme de risque; ce dossier ne mesure pas une réduction de l'ensemble d'anonymat dans un déploiement nommé.

RFC 9849 traite ces écarts et le mode séparé entre façade et backend. La clé ECH ne suffit pas si une cohorte révèle un comportement propre. RFC 9934 normalise un format PEM réunissant clé privée et ECHConfigList correspondante. Cela facilite l'échange, pas l'activation. Un fichier parfait dans un contrôleur reste une intention tant que chaque terminaison n'a pas prouvé qu'elle l'utilise.

La cryptographie sous-jacente est HPKE, définie par RFC 9180. Elle sécurise l'enveloppe. Elle ne synchronise ni TTL, ni cache, ni secret distribué.

La prime à l'intégration

Un fournisseur qui opère DNS et terminaison peut préparer la clé, vérifier la flotte, publier, maintenir le chevauchement et observer les retries dans une même frontière. Cloudflare indique qu'ECH est activé par défaut pour les zones Free et configurable ailleurs. Ce fait ne donne pas un taux universel de succès; il montre comment l'adoption devient une propriété de plateforme.

Un domaine multi-CDN doit choisir entre configuration commune, plusieurs liaisons de service ou propriétés différentes selon le chemin. Garde des secrets, TTL, cache, rollback et preuve de disponibilité deviennent des clauses entre fournisseurs. La norme autorise cette architecture; elle ne tient pas la réunion de changement à la place des opérateurs.

Le verrouillage apparaît lorsque la seule preuve de cohérence reste dans le graphe interne d'un fournisseur. Migrer revient alors à reconstruire les clés et l'historique de confiance. Des reçus exportables — hashes, horodatages, cohortes, acceptations et rollback — sont l'assurance de portabilité.

Cette conclusion sur la coordination et le verrouillage est une inférence analytique tirée des surfaces de contrôle, non une situation de marché observée. Le propriétaire du domaine paie la planification du chevauchement et la portabilité; le fournisseur DNS, la publication, le TTL et la preuve des caches; l'opérateur edge, la distribution du secret, la télémétrie et le rollback; l'entreprise, les tests de politique du résolveur et le support; l'utilisateur, les premiers essais échoués et la latence de retry. Le contrat peut déplacer argent et travail, pas les supprimer.

Un critère que l'on peut réfuter

Pour chaque rotation, conserver le hash d'ECHConfigList, les observations DNS, le TTL, l'ensemble edge attendu, les instants d'activation, l'acceptation au premier essai, les retries, la latence, les désactivations sûres, les échecs et le retour arrière.

La thèse doit être rejetée ou fortement affaiblie si des rotations répétées montrent que le DNS n'expose la nouvelle configuration qu'après préparation d'au moins 99,999 % des edges, que les divergences restent sous 0,01 %, que le retry coûte moins de 25 ms au p99, que les anciennes versions disparaissent avant TTL plus 30 secondes et que des bascules multi-fournisseurs obtiennent le même résultat sans orchestration propriétaire commune. Elle est renforcée si plus de 1 % des premiers essais nécessitent un retry, si une cohorte reste incohérente au-delà de deux TTL ou si le rollback dépasse 300 secondes.

Ces seuils sont prospectifs. Ils ne décrivent pas le marché actuel; ils indiquent comment éviter de le décrire au moyen d'un bouton.