ECH: What It Actually Solves, and What It Does Not

Encrypting the name in a TLS handshake closes one leak and leaves the rest untouched. What stays visible, why the anonymity set decides, and when it is a liability.

2026-08-31 GIGATAP Team #vpn
#vpn#anticensorship#tls#ech#dns#privacy

ECH: What It Actually Solves, and What It Does Not

Encrypting the name inside a TLS handshake gets discussed as though it solved visibility outright. The phrasing “turn it on and nobody sees where we are going” comes up constantly. It is wrong, and working out why is more useful than the mechanism itself: exactly one field gets closed, and everything else stays exactly where it was.

What is visible in an ordinary handshake#

The start of a secure connection travels in the clear — otherwise the two sides could not agree on how to encrypt anything.

That cleartext opening contains a field carrying the name of the site the client is asking for. The server needs it to know which of the sites it hosts is being requested.

client ──────────────────────────► server
        start of the handshake
        ├── destination address ← visible to everyone
        ├── SITE NAME           ← visible to everyone
        ├── list of algorithms  ← visible to everyone
        └── ...

An observer in the middle reads the name without decrypting anything. That is where name-based filtering comes from.

What ECH changes#

The mechanism encrypts the part of the handshake holding the name. An outer name — shared, public — is exposed instead, while the real name travels inside, encrypted.

WITHOUT ECH                  WITH ECH
├── address                  ├── address          ← still visible
├── NAME: our-site           ├── name: shared     ← visible but useless
└── ...                      ├── [encrypted]
                             │    └── name: our-site
                             └── ...

Note that exactly one field was closed. Everything else stayed where it was.

What remains visible#

This is the main part, and it is usually underspecified.

What Hidden by ECH?
Site name in the handshake yes
Destination address no
Who owns the address no
Packet sizes and timings no
Client library fingerprint no
The fact of a secure connection no
The DNS lookup, if unprotected no

The destination address is not a detail. If one site sits at that address, hiding the name achieves nothing: the address answers the same question.

The anonymity set#

Hence the central notion that determines the mechanism’s value.

ECH’s protection equals the number of sites made indistinguishable behind one address and one outer name.

STRONG CASE
address X ──┬── site A
            ├── site B
            ├── ... thousands of sites
            └── your site      ⇒ the name is meaningfully hidden

WEAK CASE
address Y ──── your site        ⇒ the name is encrypted,
                                  but the address says everything

A formulation that saves a lot of time: ECH hides you in a crowd, and all its protection is the size of that crowd. Your own server on your own address forms no crowd, and enabling the mechanism there changes the format of the leak rather than its existence.

The dependence on DNS#

The second limitation, less obvious.

To encrypt the name the client needs the server’s public key. It is published in DNS, in a special record the client fetches before connecting.

A chain follows:

If the DNS query is visible, so is the request for that specific name’s key. The leak moves rather than disappears.

If the DNS answer can be forged or stripped, the client will not obtain the key and will connect the ordinary way, exposing the name. The mechanism falls back silently, with no error.

Hence the rule: ECH without protected DNS does not deliver the property it claims. That is not a “preferably” recommendation but a condition of it working at all.

Why is it a liability in some countries?#

There is an effect that breaks intuition. It concerns not the mechanism’s own properties but how widespread it is on the network around you.

The mechanism helps when it is widespread. If most connections use it, its presence says nothing about a user. If a minority does, using it becomes a trait in itself.

Several jurisdictions restrict connections that carry the mechanism; Russia has done so since November 2024. That inverts the picture:

Situation Effect of the mechanism
Widely used conceals, works as designed
Rare singles the user out
Restricted the connection does not go through

The practical conclusion is unwelcome but unambiguous: where the mechanism is restricted, enabling it makes things worse. It not only fails to help, it adds a trait.

Worth knowing separately about the decoy variant: browsers can send a dummy — a field that looks like an encrypted name but carries nothing. The point is to stop the field’s presence from singling out those who actually use it. Where the mechanism is restricted, the restriction usually covers the dummy too — blending into the crowd does not work, because there is no crowd.

A numeric example#

Three placements compared by what enabling the mechanism buys.

Placement Sites behind the address What ECH gives Net
Large CDN ~10⁵ name hidden among many substantial
Small hosting ~50 narrowed to 50 options slight
Own server 1 the address answers the question nothing
Own server, restricting country 1 a trait added worse than off

The spread between the first and last rows is the difference between “works” and “harms” with the same mechanism enabled. What decides is not the mechanism but the placement context.

When to enable it#

A short criterion that replaces a long discussion.

Worth enabling if your resource shares an address with a large number of unrelated sites, DNS is protected, and the target networks do not restrict the mechanism.

Pointless if the resource has its own address: you are then encrypting a field that duplicates visible information.

Harmful if the target network restricts it: you add a distinguishing trait and a chance of failure.

Conclusion#

The mechanism solves a narrow and real problem: it removes the name from the cleartext part of the handshake. It does not hide the address, does not change traffic shape, and does not cancel the remaining traits.

Two things to remember. First: the protection equals the size of the set you hide inside — on your own address that size is one. Second: a privacy property depends on how widespread the mechanism is around you — a rare concealment tool singles you out instead of concealing.

Terms#

  • Anonymity set - the number of resources made indistinguishable behind one address and one outer name.
  • Outer name - the public name exposed instead of the real one when the handshake name is encrypted.
  • Field decoy - sending a dummy that resembles an encrypted name, so the field’s presence singles nobody out.

FAQ#

Does ECH hide where I am going?#

No. It hides the name in the handshake, but the destination address stays visible and often answers the same question.

Is it worth enabling on my own server?#

Usually not. If one resource sits behind the address, the anonymity set is one and there is nothing to hide in.

What happens if the mechanism is restricted on the network?#

The connection will not go through, and the attempt itself adds a distinguishing trait. On such networks enabling it makes things worse.

Further reading#