ECH activé, mais SNI toujours visible : comment vérifier le chiffrement du nom de domaine en 2026

ECH — le chiffrement du nom de domaine dans la poignée de main TLS — a obtenu le statut de norme en mars 2026 (RFC 9849, Standards Track). Firefox et Chrome l'incluent par défaut, Cloudflare distribue les clés à presque tous ses clients. Cependant, pour la plupart des utilisateurs, ECH ne fonctionne pas silencieusement : le navigateur revient à une poignée de main classique, et le fournisseur voit toujours où vous allez.

Ci-dessous, comment vérifier en une minute si votre SNI est chiffré, pourquoi il ne l'est souvent pas, et dans quels scénarios ECH est fondamentalement inutile (spoiler : pour l'anti-détection et le parsing — presque toujours).

Ce que cache ECH — et ce qu'il ne cache pas

Dans le TLS 1.3 classique, tout est chiffré, sauf le premier message — ClientHello. Dans celui-ci, le champ SNI avec le domaine auquel vous vous connectez est en texte clair. C'est précisément sur le SNI que reposent la plupart des systèmes de filtrage : une adresse IP pour des milliers de sites derrière un CDN, tandis que le domaine est visible.

ECH divise le ClientHello en deux :

• ClientHelloOuter — est transmis en clair, mais avec un domaine de substitution. Pour Cloudflare, c'est cloudflare-ech.com.
• ClientHelloInner — le véritable domaine, ALPN et liste de chiffrements, chiffrés avec la clé publique du serveur.

La clé pour ce chiffrement est obtenue par le navigateur non pas depuis la connexion, mais depuis le DNS — à partir de l'enregistrement HTTPS (type 65), avec le paramètre ech=. D'où la principale conséquence, souvent oubliée : ECH est impossible sans DNS chiffré. Si la requête DNS est envoyée en clair via UDP/53, un observateur voit simplement le nom de domaine avant même la poignée de main, et un résolveur filtrant peut supprimer le paramètre ech= de la réponse — et ECH ne s'activera pas.

Ce que ECH ne cache pas du tout :

• Adresse IP de destination — toujours visible ;
• volume et timings du trafic ;
• empreinte TLS du client (JA3/JA4) — l'ensemble des chiffrements et des extensions reste dans la partie ouverte ;
• vous pour le site lui-même — le serveur, après déchiffrement, voit tout ce qu'il voyait auparavant.

Le dernier point est la raison pour laquelle ECH n'est pas pertinent pour contourner les systèmes anti-bot. Cloudflare, DataDome et Akamai opèrent du côté serveur : ils se moquent de savoir si le SNI a été chiffré en cours de route. Si l'objectif est de ne pas se faire repérer lors de l'automatisation, c'est un tout autre niveau qui entre en jeu : la substitution de l'empreinte TLS elle-même, comme nous l'avons discuté dans notre article sur le contournement de l'empreinte JA4 via curl-cffi.

Vérification n°1 : ECH fonctionne-t-il en ce moment (10 secondes)

Ouvrez dans votre navigateur :

https://crypto.cloudflare.com/cdn-cgi/trace

Trouvez la ligne sni=. Deux options sont possibles :

• sni=encrypted — ECH fonctionne, le nom du site est caché en cours de route ;
• sni=plaintext — ECH n'a pas été appliqué, le domaine a été envoyé en texte clair.

La même adresse via curl dans le terminal renverra toujours sni=plaintext — le curl classique ne sait pas gérer ECH, et c'est un bon repère : c'est ainsi que cela ressemble à « désactivé ».

Vérification n°2 : le domaine a-t-il une clé ECH (dig, sans navigateur)

ECH s'activera uniquement si le domaine a un enregistrement DNS HTTPS avec le paramètre ech=. Vérifions l'enregistrement brut :

dig +short TYPE65 example.com @1.1.1.1

Dans la réponse, recherchez les octets FE0D — c'est le code d'extension ECH, suivi de ECHConfig. Exemple pratique : au moment de la rédaction de cet article, crypto.cloudflare.com et notre domaine proxycove.com avaient un enregistrement de 133 à 136 octets contenant à la fois FE0D et le nom de substitution cloudflare-ech.com en hexadécimal. En revanche, l'enregistrement de cloudflare.com est court, 61 octets : seulement ALPN et indications IP, sans ECH. Cela signifie que même au sein de l'infrastructure de Cloudflare, ECH n'est pas distribué à tous les domaines sans distinction — ne soyez pas surpris si un site particulier ne l'a pas.

Si dig se plaint de ignoring invalid type HTTPS — vous avez une ancienne version de l'outil, utilisez la forme numérique TYPE65, comme dans la commande ci-dessus.

Pourquoi ECH ne s'active pas chez vous : cinq raisons dans l'ordre

1. DNS chiffré désactivé. Sans DoH, le navigateur ne recevra pas ECHConfig de manière fiable. Dans Firefox : Paramètres → Confidentialité → DNS via HTTPS en mode « Élevé » ou « Protection maximale ». Dans Chrome : Paramètres → Sécurité → Utiliser DNS sécurisé.
2. Le domaine n'a tout simplement pas d'enregistrement HTTPS avec ech= — vérifié avec la commande du bloc précédent. Cela ne dépend de vous en rien, c'est une décision du propriétaire du site et de son CDN.
3. Le résolveur supprime le paramètre. Les serveurs DNS d'entreprise et de fournisseur sont généralement capables de renvoyer des enregistrements HTTPS sans ech=. Vérifiez en demandant l'enregistrement directement à un résolveur public (@1.1.1.1) et en le comparant avec la réponse du système.
4. Les drapeaux du navigateur ont été réinitialisés. Dans Firefox, vérifiez network.dns.echconfig.enabled et network.dns.http3_echconfig.enabled dans about:config — les deux doivent être true.
5. Un passerelle inspectant est en place. C'est le sujet de la section suivante.

Comment ECH est contourné : deux schémas différents

Firewall d'entreprise : dégradation silencieuse

Les fournisseurs d'équipements réseau ont publié des recettes prêtes à l'emploi contre ECH — ils ne sont pas prêts à perdre la visibilité du trafic. Cisco, par exemple, depuis la base d'applications VDB 416 (octobre 2025), définit « ECH Servers » comme une application distincte et propose deux approches : intercepter la connexion avec recréation du certificat et supprimer l'extension encrypted_client_hello du ClientHello, ou agir plus simplement — au niveau DNS : bloquer les enregistrements HTTPS pour les domaines ECH, couper DoH/DoT/DoQ, bloquer le domaine canari use-application-dns.net et autoriser le DNS uniquement sur les serveurs d'entreprise.

La ruse du premier schéma est qu'il ne ressemble pas à un blocage. Le serveur, ne voyant pas l'extension ECH, répond comme d'habitude, le client considère ECH comme « désactivé en toute sécurité » et se reconnecte déjà avec un SNI ouvert. Le site s'ouvre, aucune erreur n'est signalée — et le nom de domaine est enregistré dans le journal de la passerelle.

Niveau national : la connexion meurt simplement

L'exemple russe est révélateur par sa précision. Depuis le 5 novembre 2024, le filtrage ne s'active que lorsque deux critères sont remplis simultanément : SNI avec la valeur cloudflare-ech.com plus la présence de l'extension ECH. Séparément, aucun des deux ne provoque de blocage — ECH passe à d'autres domaines de substitution (par exemple, les tests defo.ie ou tls-ech.dev). Cela est réalisé non pas par une réinitialisation de la connexion, mais par un rejet silencieux des paquets : la page reste bloquée et se déconnecte par timeout. Cela touche à la fois HTTP/2 basé sur TCP et QUIC/HTTP-3. Le Roskomnadzor a alors déclaré que l'utilisation de TLS ECH violait la législation russe et a recommandé aux propriétaires de sites de quitter le CDN Cloudflare — des milliers de ressources parfaitement légales ont été frappées par le filtre, toutes incluses dans la même enveloppe.

Dans une telle situation, Firefox réessaie environ une minute plus tard sans ECH — c'est-à-dire qu'il finit par donner un SNI ouvert, ce que la spécification ne recommande pas de faire pour des raisons de sécurité. Si vous observez « le site se charge exactement une minute, puis s'ouvre » — c'est presque certainement cela.

Quand ECH n'est pas suffisant et quoi mettre à la place

Décomposons les tâches honnêtement.

• Confidentialité vis-à-vis du fournisseur sur Internet domestique. ECH + DoH — une amélioration bonne et gratuite. Cela fonctionne là où il n'est pas coupé.
• Contourner le filtrage. ECH n'a pas été conçu pour cela, et la pratique l'a confirmé : dès qu'il a commencé à gêner les filtres, ils ont appris à le détecter et à le couper complètement. Ne comptez pas sur lui comme un outil d'accès.
• Parsing, multi-comptes, automatisation. ECH ne donne rien : le site cible voit votre IP, votre JA4 et votre historique de requêtes. Seuls l'IP source et la qualité de l'empreinte comptent.

Dans tous les cas où ECH ne fonctionne pas, un niveau plus grossier mais fiable fonctionne : déplacer la poignée de main TLS en dehors du réseau observable. Lorsque le trafic passe par un proxy, l'observateur sur votre canal ne voit que la connexion avec le nœud proxy — aucun SNI du site cible n'est présent, peu importe si le domaine prend en charge ECH ou non. Pour un accès quotidien et le travail avec des services sensibles à la réputation de l'IP, des proxies résidentiels conviennent ; pour des applications mobiles et des plateformes particulièrement exigeantes sur le type de connexion, des mobiles.

Et n'oubliez pas le DNS : un proxy dans le navigateur ne garantit pas que les noms sont résolus par lui-même. Une fuite DNS révèle exactement ce que vous essayiez de cacher — comment vérifier cela a été discuté dans un guide séparé sur la vérification des proxies pour les fuites DNS. Si la question concerne une analyse approfondie du trafic sur le canal, il faut se concentrer non pas sur ECH, mais sur le transport lui-même.

Liste de vérification rapide

1. Ouvrir crypto.cloudflare.com/cdn-cgi/trace et vérifier la ligne sni=.
2. Si plaintext — activer DoH dans le navigateur et vérifier à nouveau.
3. Si cela n'a pas aidé — vérifier la présence de la clé pour le domaine : dig +short TYPE65 domaine @1.1.1.1, chercher FE0D.
4. La clé est présente, mais ECH n'est pas appliqué — comparer la réponse des résolveurs publics et système : il est probable que le paramètre soit supprimé en cours de route.
5. La connexion reste bloquée pendant une minute et s'ouvre — ECH est coupé au niveau du réseau ; ECH ne pourra pas aider ici, un autre transport est nécessaire.

Conclusion

ECH est la dernière faille soigneusement fermée dans la confidentialité du TLS, et non un moyen d'accès, et encore moins un outil d'automatisation. Il dépend du DNS chiffré, se désactive silencieusement sans aucune erreur à l'écran et est complètement coupé là où il commence à gêner. Il vaut la peine de le vérifier — les deux commandes ci-dessus prennent une minute. Mais fonder des contournements de blocages ou une protection contre les systèmes anti-bot sur lui est inutile : ces tâches se résolvent au niveau de l'IP et de l'empreinte TLS que le serveur voit de l'autre côté.