Protocole ECH dans TLS : qu’est-ce que c’est et à quoi ça sert ?

ECH, pour Encrypted ClientHello, est une extension conçue pour réduire une fuite de confidentialité longtemps inhérente aux connexions HTTPS : le nom du site demandé pouvait rester visible au début de l’échange TLS. Standardisé par l’IETF dans la RFC 9849, ECH s’appuie sur TLS 1.3 pour chiffrer les informations les plus sensibles du premier message envoyé au serveur. Il ne rend pas la navigation anonyme, mais il empêche plus souvent un observateur réseau de déduire directement le domaine visité.

ECH dans TLS : le chiffrement de l’indication de nom du serveur

Le rôle du SNI dans une connexion HTTPS

Avant d’établir une session chiffrée, le navigateur envoie un message nommé ClientHello. Il y propose notamment les versions TLS et algorithmes cryptographiques qu’il accepte. Ce mécanisme est détaillé dans le fonctionnement de TLS lors d’une connexion HTTPS. Dans ce message figure généralement le SNI, ou Server Name Indication. Cette extension indique le nom de domaine auquel le client souhaite se connecter, par exemple www.exemple.fr. Elle est indispensable dans de nombreux cas : une même adresse IP peut héberger plusieurs sites HTTPS, chacun avec son certificat. Le serveur doit donc connaître le nom attendu avant d’envoyer le bon certificat et de poursuivre la négociation. Le SNI ne doit pas être confondu avec le certificat lui-même. Il sert à orienter la connexion vers le bon hôte virtuel ; le certificat permet ensuite au navigateur de vérifier l’identité du serveur. Pour approfondir cette distinction, voir l’extension SNI dans TLS.

Les informations exposées sans ECH

HTTPS chiffre le contenu des échanges après la négociation TLS : pages, formulaires, cookies et requêtes ne sont pas lisibles par un tiers passif. Toutefois, dans les déploiements traditionnels, le SNI du ClientHello reste en clair. Un fournisseur d’accès, un administrateur de réseau Wi-Fi ou un dispositif de filtrage peut alors observer le domaine demandé, sans accéder au contenu de la page. Cette visibilité permet l’inspection passive des métadonnées, mais aussi des politiques de classification ou de blocage fondées sur le nom de domaine. ESNI, pour Encrypted SNI, a constitué une première tentative expérimentale de chiffrer uniquement cette indication. ECH lui succède avec une portée plus large : il protège une partie substantielle du ClientHello, plutôt qu’une seule extension.

Comment fonctionne le protocole Encrypted ClientHello

Le ClientHello externe, l’Inner ClientHello et la clé publique du serveur

Avec ECH, le navigateur prépare deux représentations de sa demande. L’Inner ClientHello contient le véritable SNI ainsi que les extensions que le protocole doit garder confidentielles. Il est chiffré. L’Outer ClientHello, lui, reste visible sur le réseau : il transporte le contenu chiffré et affiche un nom de couverture, appelé public name. Ce chiffrement utilise HPKE, pour Hybrid Public Key Encryption, défini par la RFC 9180. Avant la connexion, le client obtient une ECHConfig, c’est-à-dire une configuration publique contenant notamment une clé publique et les paramètres cryptographiques admis. Avec cette clé, il chiffre l’Inner ClientHello sans disposer au préalable d’un secret partagé avec le serveur. Seul le serveur, ou l’équipement qui termine TLS pour son compte, détient la clé privée correspondante. Le déroulement peut se résumer ainsi :

• le client récupère une ECHConfig ou une ECHConfigList valide ;
• il chiffre l’Inner ClientHello au moyen de la clé publique publiée ;
• il envoie un Outer ClientHello contenant le message chiffré ;
• le serveur déchiffre le message, sélectionne le bon site et confirme l’acceptation d’ECH.

La confirmation d’acceptation est elle-même cryptographiquement liée à la session : elle évite qu’un intermédiaire puisse faire croire au client qu’ECH a fonctionné alors que le serveur ne l’a pas traité.

Le rôle de DNS HTTPS et des enregistrements HTTPS/SVCB

Pour chiffrer correctement le premier message, le navigateur doit connaître la configuration ECH avant la connexion TLS. Celle-ci peut être distribuée via le DNS, notamment grâce aux enregistrements SVCB et HTTPS. Leur paramètre ech transporte une ECHConfigList, soit une liste de configurations que l’infrastructure accepte. Cette publication DNS soulève deux enjeux distincts. DNSSEC authentifie les données DNS lorsqu’il est déployé ; il ne chiffre pas les requêtes. À l’inverse, DoH et DoQ chiffrent le transport entre l’appareil et son résolveur, sans garantir à eux seuls l’authenticité de chaque réponse. Le fonctionnement de DNS over HTTPS éclaire cette différence. Une configuration ECH falsifiée ou obsolète peut empêcher la négociation, d’où l’importance de mécanismes DNS et opérationnels cohérents.

Ce que ECH protège réellement — et ce qu’il ne masque pas

Les gains de confidentialité pour la navigation web

Le bénéfice principal est précis : le nom de domaine réel n’apparaît plus directement dans le ClientHello observable, lorsque ECH est effectivement négocié. Cela complique la surveillance basée sur le SNI et limite l’exposition du domaine lors de la phase de connexion, particulièrement pour les sites partageant une infrastructure ou un CDN. ECH améliore donc HTTPS sans le remplacer. Le chiffrement applicatif demeure assuré par TLS ; la confiance dans le site dépend toujours de son certificat. Les mécanismes associés aux certificats, tels qu’OCSP Stapling et la vérification d’un certificat TLS, répondent à un autre besoin : connaître le statut du certificat sans multiplier les requêtes de contrôle.

Information	Sans ECH	Avec ECH accepté
Nom de domaine dans le SNI	Généralement visible	Chiffré dans l’Inner ClientHello
Contenu HTTPS	Chiffré après TLS	Chiffré après TLS
Adresse IP de destination	Observable	Généralement observable

Les métadonnées qui restent potentiellement observables

ECH n’est pas un outil d’anonymisation. L’adresse IP de destination reste habituellement visible, même si elle peut correspondre à de nombreux domaines lorsqu’un CDN mutualise l’hébergement. Un observateur peut aussi analyser les horaires, volumes, tailles de paquets, durée des connexions et parfois les requêtes DNS non chiffrées. Ces indices de trafic peuvent permettre des inférences, surtout si un domaine utilise une adresse IP dédiée. ECH réduit une fuite importante, mais ne supprime ni la visibilité réseau minimale nécessaire au routage, ni les corrélations possibles avec d’autres sources de données.

Compatibilité, déploiement et limites pratiques d’ECH

Navigateurs, serveurs web et réseaux intermédiaires

ECH exige une prise en charge de bout en bout : navigateur ou client TLS, résolveur capable de fournir les enregistrements appropriés, serveur ou CDN disposant des clés privées et de la configuration publiée. Le déploiement est souvent porté par des CDN, car ils gèrent déjà la terminaison TLS pour un grand nombre de domaines. Les serveurs doivent également synchroniser certificats, noms d’hôtes et clés ECH. L’obtention et le renouvellement des certificats restent séparés d’ECH, mais font partie de la même chaîne d’exploitation ; le protocole ACME pour les certificats TLS automatise précisément cette gestion.

Les risques de blocage, de repli et de mauvaise configuration

Des équipements réseau anciens peuvent mal gérer des ClientHello contenant ECH, les bloquer ou les modifier. Une ECHConfig expirée, une clé privée absente sur un nœud du CDN, ou un enregistrement HTTPS mal publié provoquent aussi des échecs. Selon la politique du client et du service, une tentative peut alors se poursuivre par un repli sans ECH, ce qui réexpose le SNI, ou échouer totalement. Le repli est utile pour la compatibilité, mais il peut affaiblir le gain de confidentialité face à un réseau qui perturbe volontairement ECH. Un déploiement sérieux doit donc surveiller la cohérence DNS, la rotation des clés, la disponibilité sur tous les points de terminaison et le comportement des clients en cas d’échec.

Le point essentiel à retenir

Encrypted ClientHello comble une limite historique de HTTPS : la visibilité du nom de domaine pendant l’ouverture d’une connexion sécurisée. En chiffrant le ClientHello interne, il réduit les possibilités d’identification ou de filtrage reposant sur le SNI, sans modifier la protection du contenu déjà assurée par TLS. Cette évolution ne rend toutefois pas le trafic invisible. Adresse IP, volume, horaires et autres indices réseau peuvent encore révéler des informations. Son efficacité dépend aussi d’une chaîne cohérente : navigateur compatible, configuration DNS fiable et infrastructure serveur correctement déployée. Pour les opérateurs de sites, la priorité consiste à vérifier la prise en charge par le CDN ou le serveur TLS, puis à surveiller les échecs de négociation et les replis. ECH doit être envisagé comme une couche de confidentialité supplémentaire, complémentaire au chiffrement DNS et à une gestion rigoureuse des certificats.

Questions fréquentes

ECH remplace-t-il un VPN ou Tor ?

Non. ECH protège principalement le nom de domaine dans la négociation TLS, mais ne masque généralement ni l’adresse IP du serveur ni l’adresse IP de l’utilisateur auprès de son fournisseur d’accès. Un VPN ou Tor répond à un objectif différent : faire transiter le trafic par un intermédiaire afin de limiter l’exposition de l’adresse source et, selon le service, de la destination.

Faut-il installer une extension de navigateur pour utiliser ECH ?

Non, lorsque le navigateur, le résolveur DNS et le site web le prennent en charge. ECH est négocié automatiquement pendant la connexion. Une extension ne peut pas compenser l’absence de configuration sur le serveur : le domaine doit publier une configuration ECH valide et son infrastructure TLS doit posséder la clé privée associée.

ECH protège-t-il aussi les requêtes DNS ?

Non. ECH chiffre le ClientHello de TLS, pas les recherches DNS effectuées avant la connexion. Pour réduire l’exposition de ces requêtes, il faut employer un transport DNS chiffré, tel que DoH ou DoQ. ECH et DNS chiffré sont complémentaires : l’un protège le démarrage TLS, l’autre le trajet entre l’appareil et le résolveur.

Pourquoi une connexion peut-elle échouer avec ECH ?

Une incompatibilité entre le client et le réseau, une configuration DNS périmée ou une clé absente sur un serveur peuvent empêcher le déchiffrement de l’Inner ClientHello. Le client peut parfois retenter la connexion sans ECH, mais ce repli dépend de son comportement et de celui du service. Un échec persistant n’indique pas nécessairement un problème de certificat.