Security Bloggers Network 
SBN

Unmasking ECH: Why DNS-at-the-Root-of-Trust Holds the Key to Secure Connectivity

Avatar photo by David on May 29, 2025

Encrypted Client Hello (ECH) has been in the news a lot lately. For some background and relevant and recent content, see:

C Suite and Security Operators’ concerns about ECH

The push for ECH primarily is of interest to privacy-seeking end users using an untrusted transit. The dynamics are at odds with security professionals responsible for their users and endpoints, regardless of transit. This blog article is written for the latter group.

There are enough motivations for ECH adoption that it is bound to happen since ECH client support is already present in modern browsers. In my own lab network, I just checked my ech logs over the last few hours. These domains have been contacted, all via ECH:

api.ecomsend.com
app.backinstock.org
cdn.discordapp.com
discordapp.com
oidc.iam.cfapi.net
textify-cdn.com
ublockorigin.pages.dev
vector.im

As articulated in Corrata’s White Paper titled “Living with ECH”, the following statement caught our attention:

“A rapid increase in the use of Encrypted Client Hello would mean that it would no longer be possible to directly detect the destination of much internet traffic. Security tools designed to keep enterprises safe would lose some of the visibility they rely on.”

In a world where security operators have good reasons to be concerned about the destination of any connection made over the internet, this is a legitimate concern, especially considering these two trends that the paper points out:

  • Phishing use:

“Our analysis of phishing detections shows that over 90% use Cloudflare infrastructure”

  • Spike in ECH adoption:

“The spike in detections of the cloudflare-ech.com domain observed in the latter part of 2024 was the catalyst for this research.”

How SNI has traditionally been used for lightweight target domain detection

Even encrypted traffic still offers the Server Name Identification in clear-text. This can be seen with a simple packet capture on any gateway, for example:

gateway#: tcpdump -i eth1 port 443 -w capture.pcap

(where eth1 is the LAN interface)

For any device on the LAN of such a gateway, can attempt to make a browser connection to www.google.com and the packet capture will contain the domain as can be extracted like this:

% tshark -r capture.pcap -Y "tls.handshake.type == 1" -T fields -e tls.handshake.extensions_server_name
www.google.com

The visited domain is available in plain text. At this point, it is trivial for the gateway security appliance to map the destination FQDN and allow (or deny) by policy. Most security appliances rely on this mechanism for detection, with or without a protective DNS resolver in play.

How SNI fails when ECH is used

If we repeat the same exercise as above for a domain where ECH is enabled, the packet capture does not include the actual visited domain, let’s use one of my visited domains from above, vector.im and we see the ech= response when making a TYPE65 query:

endpoint$ kdig @1.1.1.1 +https TYPE65 vector.im +short
1 . alpn=h3,h2 ipv4hint=172.64.80.1 ech=AEX+DQBB3gAgACCtcqyZIqDPl/JQduQQfIk5c+oiXxPWNUECS9qO7zLoIwAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:130:436c:6f75:6466:6c61:7265

gateway#: tcpdump -i eth1 port 443 -w captureECH.pcap

endpoint$ curl -v -k --ech true --doh-url https://cloudflare-doh/dns-query https://vector.im

% tshark -r captureECH.pcap -Y "tls.handshake.type == 1" -T fields -e tls.handshake.extensions_server_name
cloudflare-ech.com

Note that there’s no vector.im showing up anywhere in cleartext. Only cloudflare-ech.com is visible. This is the loss of visibility that concerns the security community.

Protective DNS to the rescue (partially)

Any available Protective DNS Resolver can block by policy on a per-FQDN basis, whether known-bad or untrusted by another assessment. However, it is only a partial solution because of the ease of the endpoint using an alternate DNS resolver, including widely-available DoH providers such as 1.1.1.1. This is a common circumvention strategy used by browsers/applications as well as by malware. In such a case, the designated Protective DNS server isn’t even in use, so it offers no protection.

The complete FIX: DNS at the root of trust

The way this is accomplished is with Don’t Talk To Strangers (DTTS) which is a default-deny-all approach for every connection, unless first permitted by policy, and subsequently looked up by adam:ONE’s caching resolver. Each destination allow-rule is permits a single source and a single destination for the period of the Time To Live (TTL) offered to the query source. This includes well-known as well as unknown DoH servers. Note that it isn’t a list of known DoH servers to block. Here’s a logical flow of the DTTS approach:

dtts

When DNS is treated as the root of trust for all network connections, every destination IP network connection is necessarily mapped back to a fully qualified domain name. The only exception to this would be for IPs that are not discovered by DNS, and are explicitly trusted.

Closing other DNS vulnerabilities

  • Hijack Do53 traffic destined anywhere except as authorized – this approach allows simultaneous convenience for any legacy endpoints using another DNS server (such as commonly hard-coded 8.8.8.8 operational devices), while still offering answers by policy
  • Offer DNS encryption internally as well as upstream via DDR and DNR standards – this approach makes the DNS environment immediately compliant with CISA DNS Security standards

Conclusion

The biggest gains with this approach can be summarized as:

  • ECH adoption no longer a security risk
  • Security-focused: from before the connection begins, security is the proactive model, not a reactive one
  • Lightweight – the replacement of the middle box now requires less horsepower, offers a faster experience with lower latency
  • Future-proofed, when DNS is treated as the root of network trust

1 post – 1 participant

Read full topic

*** This is a Security Bloggers Network syndicated blog from The ADAM Blog - ADAMnetworks authored by David. Read the original post at: https://support.adamnet.works/t/unmasking-ech-why-dns-at-the-root-of-trust-holds-the-key-to-secure-connectivity/1428

David 0 Comments