Encrypted Client Hello: A Big Tech Privacy Fix

Much of the traffic on the web is now encrypted thanks to SSL/TLS (https). This prevents attackers from seeing the contents of your traffic. But they can still see which domains you are connecting to, and that might be a problem still.

DNS-over-TLS (RFC7858) aimed to solve this, encrypting the domain names you’re requesting. Sadly, the SNI extension of client hello still leaks the domain name ¹.

Obviously, we have to encrypt the client hello. And finally, since March 3^rd 2026, we have a newly-released standard to achieve this - RFC9849 named TLS Encrypted Client Hello (ECH for short). Here's a summary flow:

While ECH definitely achieves the stated goals, I think these goals are not universal and should be re-examined. Specifically, you MUST (see RFC2119) use and trust a proxy provider (think Cloudflare) for ECH to be effective. Moreover, there are known cases when governments blocked ECH completely. I'd like to see a solution that works in more general cases. I know it's hard.

Dependency on a 3rd party for internet standards is a new one. That's not the internet I know and love. While Encrypted Client Hello brings improvements to a very hard problem, we should strive for standards that everyone can benefit from.

Here comes the nerdy part, where we dig deep and pick apart the encrypted client hello mechanisms to see how exactly this works.

Please do not attempt to play a drinking game when you take a shot each time you see a RFC document reference. Especially beware of footnotes and external links.

The original ECH RFC9849 doesn’t specify how the client gets the key to actually encrypt the client hello. As an example, it points to RFC9848 with the support of Service binding over DNS RFC9460. Note that this is only a recommendation - clients can have ECH configs pre-configured or they might use a different mechanism.

DNS-over-TLS was here first (RFC7858), using the SVCB records. Generally speaking, they point subdomains to subdomains and give additional parameters in the meantime. They are not easy to come by, here’s one I found from google:

ALPN or Application Layer Protocol Negotiation (see RFC7301) is basically a hint on the DNS level on what protocol the client is using. See a list of known ALPNs, managed by IANA. Here, h2 is HTTP/2 (RFC9113), h3 is HTTP/3 (RFC9114) and dot is DNS-over-TLS (RFC7858).

So this basically says, if you’d like to use http to get DNS data, use this endpoint like so. Of course, you have to ² use the DNS binary format as specified in RFC1035. Here’s a PoC in action:

The IP starts at offset 0x33 or 51.

I’m slightly sad that they didn’t mention the much more natural JSON endpoint, but I guess the format doesn’t allow for sufficient API description. Here’s an example:

Similar in intent, different in target we have the HTTPS record. It’s not exactly easy to find sites that have this enabled properly. After a lot of digging (ba-dum-ts), I’ve found this random Firefox bug that showcases the setup for static.certitudes.org:

And there it is - the asymmetric key to be used for encryption of the client hello.

Work on ECH RFC9849 started all the way in 2018. After many versions documented in many emails it was released on 3^rd March 2026.

We've explored RFC9848 and RFC9460 as a recommended config to get ECH public keys from DNS records, but how do we actually apply them? Let's pull the diagram again:

While you can use ECH directly with a server, this provides little benefit as with reverse DNS and other tricks you can figure out where the connection goes to anyway. So there's a proxy, hopefully proxying enough targets that you can get lost in the noise.

Then this proxy decrypts encrypted client hello so that you can establish a TLS directly with your target. Let's take a look at what this means.

The client first reaches out to the server to agree on a key to encrypt the comms with as well as to verify the certificate (identity) of the server. This is called a TLS handshake. Since the client reaches out to the server, the first message sent from the client is “Client Hello” message describing the client capabilities and intents.

Over the course of time and several SSL/TLS versions³, the handshake evolved. For backwards compatibility, this is mainly done via extensions, here’s a TLS 1.0 client hello structure (RFC3546):

Then an extension has a following structure:

You see that this structure is very liberal. This is great, because older clients/servers can pick extensions by the IDs which they understand and can just ignore extensions with other IDs.

Here’s a IANA managed list of currently known IDs for reference.

Now that we know how a client hello looks like and what is an extension, we can take a look at ECH implementation.

The idea is to keep all of the relevant client hello extensions (here we care mainly about SNI (RFC8744)), but fill those with bogus data. The doc refers to these extensions as the outer client hello. The client has the same extensions with real data encrypted in another extension (id 65037 or 0xfe0d). This is referred to as the inner client hello.

The standard specifies that a selected HPKE AEAD scheme is to be selected (see RFC9180 or the upcoming draft). Without going too deep here - AEAD is authenticated encryption with associated data - keeping some parts encrypted, some plain but all with a cryptographically ensured integrity. Good stuff, as always.

If the client wishes to keep some of the extensions non-encrypted, it can instruct the server to look for the values using the ech_outer_extensions extension (id 64768 or 0xfd00). This can reduce the size of the handshake.

The server has option to ignore an unknown extension and work with what the client provided in the open. The client has to detect this and realize the encrypted client hello was rejected. Depending on the intent, the client might just give up, thus preserving privacy.

After the server processes the encrypted client hello, the rest of the handshake resumes normally. If the client detects the server didn't correctly decrypt ECH, it has the option to abort.

One last point to raise here - the client has the option of sending a completely bogus inner client hello. The server should reject it. This is part of the GREASE efforts (RFC 8701), where clients troll the servers and middle boxes to force them into implementing the standards properly.

You can still see the destination IP address. Then using a reverse DNS you can figure out what am I connecting to. And yes, setting it up is a best practice, especially for email servers.

There is a scenario, where reverse DNS doesn’t matter. And nowadays it’s quite common. The real site hides behind one of the “firewall” providers like Cloudflare, Akamai, Fastly and others. All you can see under the reverse DNS is that service, like so:

This is the real world scenario where ECH has benefits.

There is no real way of deploying this without having a big strong proxy providing anonymity to the connections. You need to get lost in the requests to the proxy that have many different targets.

The authors of the RFC9849 acknowledge this in section 10.1, par 7:

With regards to handshake privacy, client-facing server configuration determines the size of the anonymity set. For example, if a client-facing server uses distinct 'ECHConfig' values for each server name, then each anonymity set has size k = 1. Client-facing servers SHOULD deploy ECH in such a way so as to maximize the size of the anonymity set where possible.

So unless you host many webs, encrypted client hello has little benefits for your site.

The internet was designed as a peer-to-peer network that is decentralized and resilient. Unrestricted by borders, languages, vendors and others. This property erodes over time as the control becomes more centralized. That model is gone. That internet is gone. That freedom is gone.

Nowadays we have couple of big players, be them big providers running your sites (AWS, Azure), running couple of used applications (Meta, Google) hiding behind CDNs (Cloudflare, Akamai). The borders are back, the big Chinese firewall is one such example, but there are others. Read the news - cloudflare goes down and 20% internet is now silent. Read similar stories about AWS or Azure. Without spiraling too much, let me just say their public trust is lower than it used to be.

It's easy to see how we got here. Supporting your own IT is hard and these companies have great products for great prices. Moreover, these costs are predictable as opposed to random fluctuations of your own IT department and associated headaches. Economies of scale exist for a reason - normal people don't care about IT and why should they?

I don’t want to throw dirt on these companies or this standard. But I have to admit that this direction of centralization bothers me. And I’m not alone - it seems that the EU has realized the same and is trying to fix this with the digital sovereignty movement.

Keeping on topic - if you wish to use ECH, you have to trust these companies. It bothers me that we have a standard that’s only deployable in huge companies.

Governments are able to target ECH packets to drop them, effectively forcing ECH away. Then SNI is inspected and based on the target domain the connection might be dropped. In that sense, ECH is very comparable to VPNs. The ISPs or company networks can do that too.

If you really worry that somebody is sniffing your packets, we have an old solution: TOR. Commonly associated with the dark web, TOR is an anonymization technology ran by plenty of volunteers. TOR is much older with a much better track record. Of course, the providers don’t think this is a good approach. Of course, TOR has issues too. I’m not sure how well it guards your privacy - fingerprinting/blocking exit relays is a no-brainer thing to do.

We only need ECH because we need to encrypt SNI. We need SNI because we have NAT and we have NAT because we don't have enough IPv4 addresses. Depending on who you talk to, they will either praise NAT or curse NAT. As an exercise for the reader, think about IPv6 options to disable SNI. For most servers you don't need to support reverse DNS (that's not a silver bullet either though).

Another angle to look at ECH is the security model proposed in the RFC9849. I'm saying that model has a gap. When your adversary has the option of eliminating all of the traffic that would use this standard, you have three options:

1. Stay quiet, don't send any traffic,
2. Drop the enhanced security,
3. Try and get away from that adversary.

There are cases when you can't afford either of these.

Another assumption that can be challenged is that of a trusted client-facing server. I'd recommend really checking your threat model to see if you can afford this trust.

Last point: check if the need for ECH isn't in contradiction with the assumptions above. This can be more simply stated as: when you need such privacy it can be quite easily removed/blocked and when you don’t need it that much... then why bother?

Dependency on a 3rd party for internet standards is a new one. That's not the internet I know and love. While Encrypted Client Hello brings improvements to a very hard problem, we should strive for standards that everyone can benefit from.