Client Hello et DoH chiffrés : ce que les pare-feu de périmètre ne peuvent plus voir

Depuis vingt ans, les pare-feu réseau et les proxys se sont appuyés sur un champ non chiffré pour savoir où allait le trafic chiffré : l'indication du nom du serveur (SNI), le nom d'hôte qu'un client annonce dans le premier message d'une poignée de main TLS. DNS sur HTTPS (DoH, RFC8484) masquait déjà la recherche DNS qui précède une connexion. Encrypted Client Hello, désormais publié sous le nom RFC9849, masque le SNI lui-même. Ensemble, ils suppriment les deux signaux sur lesquels la plupart des filtrages de sortie ont été construits.

Comment fonctionne ECH : un client interne et externeBonjour

Avec ECH, le client crée deux messages ClientHello. La clé interne contient la destination réelle et les paramètres sensibles et est cryptée avec HPKE sur une clé publique publiée par le serveur à l'avance. Le nom externe, envoyé en clair, porte un nom public partagé, généralement le nom du frontal du fournisseur, de sorte qu'un observateur apprend uniquement que le client parle à ce fournisseur (RFC9849; Explication de Cloudflare).

TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

D'où vient la clé : l'enregistrement DNS HTTPS

Le client a besoin de la clé publique ECH du serveur avant la prise de contact. Il l'obtient du DNS, dans l'enregistrement de ressource HTTPS (type 65, RFC9460), dont le paramètre ech porte une ECHConfigList. Nous en avons interrogé un vrai. Le dig livré avec macOS ne connaît pas l'enregistrement par son nom, alors demandez-le par numéro :

$ dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com

Si cette requête DNS elle-même transite via DoH, un observateur du réseau ne voit ni la recherche ni, avec ECH, le nom d'hôte dans la poignée de main. C’est la combinaison sur laquelle porte cet article.

L'utilisation ou non d'ECH dépend du client

ECH n'est pas quelque chose qu'un réseau active ; chaque client décide. Les navigateurs ont fourni un support (État de la plate-forme Chrome), généralement lié à l'utilisation du DNS crypté. De nombreux logiciels ne l'utilisent pas du tout. Le point de terminaison de trace de Cloudflare rapporte ce qu'il a reçu, et le curl intégré à macOS envoie toujours le nom d'hôte en clair :

$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext

Le tableau réaliste d’aujourd’hui est donc un mélange : les navigateurs cachent de plus en plus le nom d’hôte, de nombreux autres programmes ne le font pas, et les logiciels écrits pour échapper à la surveillance peuvent choisir d’utiliser délibérément ECH et DoH.

Ce qu'un pare-feu périmétrique perd et ce qu'il conserve

Le résumé honnête est que le filtrage basé sur le nom d’hôte à la périphérie cesse de fonctionner pour le trafic ECH, contrairement aux contrôles basés sur IP. Un réseau peut toujours refuser les connexions aux résolveurs DoH connus, ce qui, en pratique, empêche également les navigateurs d'obtenir des clés ECH via un DNS crypté, et il peut toujours bloquer des plages d'adresses. Ce qu'il ne peut plus faire, c'est distinguer deux sites derrière le même fournisseur, ou autoriser l'un et bloquer l'autre, sans interrompre TLS de la manière qu'ECH est conçu pour détecter.

La visibilité se déplace vers le point final

Le seul endroit où le nom d'hôte n'est jamais caché est la machine qui établit la connexion : le programme l'a demandé par son nom. C'est pourquoi ECH déplace le contrôle de sortie vers le point final. Un pare-feu basé sur l'hôte n'a pas du tout besoin de lire la négociation ; il voit quel processus a ouvert la connexion, à quelle adresse et, lorsque le programme a résolu un nom, quel nom, avant que les octets chiffrés ne disparaissent. Il voit également la seule chose qu'un périphérique réseau n'a jamais pu voir, même avant ECH : quelle application sur la machine parle.

• Décidez par application, pas par nom d'hôte : un navigateur, un client de synchronisation et un binaire inconnu ont des règles différentes.
• Traitez un programme qui démarre son propre DoH avec un résolveur que le système n'a pas configuré comme un signal qui mérite le détour.
• Gardez les listes de blocage basées sur IP à la périphérie ; ils fonctionnent toujours et ils ne coûtent rien.

Le rôle de FireAI et de HisnLabs

ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.

FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.

Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.