Encrypted Client Hello and DoH: What Perimeter Firewalls Can No Longer See

For twenty years, network firewalls and proxies have leaned on one unencrypted field to know where encrypted traffic was going: the Server Name Indication (SNI), the hostname a client announces in the first message of a TLS handshake. DNS over HTTPS (DoH, RFC 8484) already hid the DNS lookup that precedes a connection. Encrypted Client Hello, now published as RFC 9849, hides the SNI itself. Together they remove the two signals most egress filtering was built on.

How ECH works: an inner and an outer ClientHello

With ECH, the client builds two ClientHello messages. The inner one carries the real destination and sensitive parameters and is encrypted with HPKE to a public key the server published in advance. The outer one, sent in the clear, carries a shared public name, typically the name of the provider’s front end, so an observer only learns that the client is talking to that provider (RFC 9849; Cloudflare’s explainer).

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

Where the key comes from: the HTTPS DNS record

The client needs the server’s ECH public key before the handshake. It gets it from DNS, in the HTTPS resource record (type 65, RFC 9460), whose ech parameter carries an ECHConfigList. We queried a real one. The dig shipped with macOS does not know the record by name, so ask for it by number:

$ 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

If that DNS query itself travels over DoH, a network observer sees neither the lookup nor, with ECH, the hostname in the handshake. That is the combination this article is about.

Whether ECH is used depends on the client

ECH is not something a network turns on; each client decides. Browsers have shipped support (Chrome Platform Status), generally tied to encrypted DNS being in use. Plenty of software does not use it at all. Cloudflare’s trace endpoint reports what it received, and the curl built into macOS still sends the hostname in the clear:

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

So the realistic picture today is a mix: browsers increasingly hide the hostname, many other programs do not, and software written to evade monitoring can choose to use ECH and DoH deliberately.

What a perimeter firewall loses, and what it keeps

The honest summary is that hostname-based filtering at the edge stops working for ECH traffic, while IP-based controls do not. A network can still refuse connections to known DoH resolvers, which in practice also keeps browsers from obtaining ECH keys over encrypted DNS, and it can still block address ranges. What it can no longer do is tell two sites behind the same provider apart, or allow one and block the other, without breaking TLS in ways ECH is designed to detect.

Visibility moves to the endpoint

The one place where the hostname is never hidden is the machine that makes the connection: the program asked for it by name. That is why ECH shifts egress control toward the endpoint. A host-based firewall does not need to read the handshake at all; it sees which process opened the connection, to which address and, when the program resolved a name, which name, before any encrypted bytes leave. It also sees the one thing a network device never could, even before ECH: which application on the machine is talking.

• Decide per application, not per hostname: a browser, a sync client and an unknown binary get different rules.
• Treat a program that starts its own DoH to a resolver the system did not configure as a signal worth a look.
• Keep IP-based blocklists at the edge; they still work, and they cost nothing.

How FireAI and HisnLabs fit in

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 is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its Autopilot feature) on real traffic patterns, all without any of it leaving your Mac.

You can read the technical decisions behind it, or try FireAI for 17 days, at FireAI, by HisnLabs.