Encrypted Client Hello (ECH): what it means for web filtering

What Encrypted Client Hello is

When a browser opens a secure HTTPS connection, the first message it sends is the TLS ClientHello. Even in TLS 1.3, part of that message has been sent in the clear, including the Server Name Indication (SNI): the name of the website the browser wants. The IETF describes the plaintext SNI as perhaps the most sensitive information left unencrypted in TLS 1.3, because it leaks the target domain for every connection.

Encrypted Client Hello (ECH) fixes that. It was published as RFC 9849, a Standards Track document, in March 2026, and it lets the browser encrypt its ClientHello, including the SNI and other fields, using a public key published by the server's provider. An observer on the network can see that the device is connecting to a particular provider, but not which of the sites behind that provider it wants.

The RFC is candid that ECH on its own does not hide everything. The site name can still leak through plain-text DNS lookups or through IP addresses, which is why it points to encrypted DNS as the natural partner to ECH.

How ECH works

ECH depends on DNS, which is why it matters to anyone running DNS-layer security:

1. The website's provider publishes an ECH configuration, containing a public key and a "public name" for the provider, in a DNS HTTPS record (defined in RFC 9460; RFC 9848 covers ECH specifically).
2. When the browser looks up the site, it asks for the HTTPS record as well as the usual address records.
3. The browser builds two ClientHellos: an inner one with the real site name, encrypted with the provider's key, and an outer one showing only the provider's public name.
4. The provider's front-end server decrypts the inner ClientHello and connects the browser to the right site. Everyone else on the path sees only the outer one.

The RFC also notes that ECH configurations delivered through ordinary DNS are not authenticated, so an attacker who can tamper with DNS can strip or replace them. It names DNSSEC and encrypted DNS transport as defences.

Why ECH matters for web filtering

Many network security tools have used the SNI as a cheap way to know which site a connection is going to, without decrypting it. With ECH, that signal shows only the provider's public name:

That is why the UK Safer Internet Centre's appropriate filtering definition, updated in May 2026, now names ECH alongside VPNs, proxies and DNS over HTTPS as circumvention techniques a school filter should identify and manage. It also warns that relying solely on network-level filtering may become less effective and suggests device-level configuration on school-owned devices.

Why DNS-layer filtering still sees the lookup

ECH encrypts the TLS handshake, not the DNS lookup that comes before it. A browser still has to find the site's address and its ECH configuration, and it does that through DNS. If the device uses your protective DNS resolver, the resolver sees the name being looked up and can refuse to answer for a blocked domain, just as before. No answer means no address and no ECH key, so the connection does not start.

The catch is the word "if". Pair ECH with DNS over HTTPS to a public resolver and the network sees neither the lookup nor the site name. So the controls that keep DNS on your resolver become the controls that keep ECH manageable:

• manage browsers' Secure DNS settings so lookups go to your protective resolver (see secure DNS)
• block outbound DNS on ports 53 and 853 except via your resolver, and block third-party DoH services (see should you block DNS over HTTPS?)
• use a roaming agent so laptops use your resolver off site (see DNS roaming clients)

DNS-layer filtering works at the domain level, so it cannot pick out individual pages; for that you still need a proxy. Our guide to DNS filtering vs URL filtering explains where each layer fits.

Managing ECH on managed devices

RFC 9849 itself acknowledges that some uses which depend on the information ECH encrypts may break, and suggests two enterprise approaches: disabling ECH through group policy on managed devices, with browsers honouring that setting, or intercepting and decrypting TLS connections.

The browser vendors document policies for the first approach:

Whether to disable ECH is a judgement call. It is a genuine privacy and security improvement for users, and switching it off on managed devices trades that away for visibility. For many organisations the better route is to keep DNS on a protective resolver, use device-level controls, and reserve TLS inspection for where it is needed. Browser support and policy names are changing quickly, so check each vendor's current documentation before you deploy, and confirm the policy is applied on a test device.

Schools and ECH

Schools have the clearest obligation to plan for ECH because of the UK Safer Internet Centre definition and the Department for Education's filtering and monitoring standards. A sensible approach for a school or trust:

1. Ask your filtering provider, in writing, how its system handles ECH and DNS over HTTPS, as the UKSIC definition expects providers to be transparent about encrypted traffic.
2. Keep school devices on the school's resolver, on site and off site, using device management and a roaming agent where the provider offers one.
3. Decide, with your designated safeguarding lead, whether ECH should be disabled by browser policy on pupil devices.
4. Test regularly, including off site and on guest Wi-Fi, using the approach in our school web filter test guide.

Our web filtering for schools guide covers the wider requirements.

How we help

Forever Systems can help you work out how much your current filtering relies on reading the server name, and plan for ECH with a combination of protective DNS, device policies and, where needed, a secure web gateway. As a Cisco Partner we supply Cisco DNS-layer security alongside other DNS security options, and we can help you compare them.

Contact us to talk it through. Scope is confirmed at quote; ask us for a quote.