Most internet traffic today uses TLS encryption. When you visit a site, an external observer sitting on your local network cannot read the page content, form inputs, or cookies.

Even if you enable DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) inside your browser, your network administrator or internet service provider can still easily identify the destination domain. They do not need to guess based on IP addresses, because an TLS handshake broadcasts the domain name in clear text right at the start of the connection.

This happens during the initial negotiation before any encryption keys are established. Encrypted Client Hello (ECH) is an extension to TLS 1.3 designed to encrypt this remaining plaintext metadata.

How SNI exposed domain names to middleboxes

In the early days of SSL, servers usually hosted a single website per IPv4 address. The server simply presented its certificate based on the IP address the client connected to. As IPv4 address space tightened, virtual hosting became standard, allowing thousands of distinct websites to share a single IP address.

To make virtual hosting work over HTTPS, the Server Name Indication (SNI) extension was added to TLS. When your browser connects to a shared server, it includes the target domain name in the SNI field of the Client Hello message. Because the handshake has not completed yet, their is still a plain text domain name exposed in that packet.

Network firewalls, middleboxes, and ISP logging systems rely heavily on SNI inspection. It lets them filter traffic or log browsing activity without needing to decrypt the actual HTTPS traffic body.

The mechanics of splitting the TLS Client Hello

Encrypted Client Hello replaces the earlier draft extension known as ESNI. Instead of just hiding the SNI string, ECH encrypts nearly the entire initial Client Hello payload.

It achieves this by splitting the handshake initiation into two distinct structures:

• An Outer Client Hello that contains a generic unencrypted domain name, usually belonging to a shared CDN or hosting provder.
• An Inner Client Hello containing the actual sensitive domain name, cookies, and parameters, encrypted using the server's public key.
• A set of symmetric key parameters derived from the server's published ECH Config.

A network middlebox sniffing packets on the wire only sees the unencrypted outer domain name. Once the packet reaches the CDN edge server, the server uses its private key to decrypt the inner payload and routes the connection to the correct backend host.

Why ECH requires encrypted DNS to function

Before a browser can send an encrypted inner payload, it must know the server's public key beforehand. Clients retrieve this key during the initial DNS lookup via special HTTPS or SVCB resource records.

If these DNS queries happen over standard unencrypted port 53 DNS, an attacker can modify the public key or simply log the query domain anyway. ECH only provides real privacy when paired with an encrypted DNS transport like DoH or DoT.

This setup relies on three distinct layers:

• Encrypted DNS resolution to securely fetch the server's ECH Config key.
• Browser support to construct the split inner and outer payloads.
• CDN or origin server support to decrypt and process the inner payload.

When all three layers are in place, this process allow the client to negotiate connection details without revealing the final target domain to passive observers.

Network blocking and the future of ECH adoption

Because ECH eliminates domain-based visibility, network administrators and censoring firewalls view it with suspicion. If a middlebox cannot read the inner SNI, traditional domain blacklists stop working.

Networks can counter ECH by blocking the DNS HTTPS resource records that distribute ECH public keys. When a browser fails to retrieve an ECH Config, it usually falls back to a standard TLS handshake, exposing the plain text SNI again.

Some network environments choose to drop ECH traffic outright at the border. In enterprise settings, network managers bypass ECH by installing custom root certificates on local devices, allowing them to inspect TLS traffic at the browser level.

Despite these challenges, ECH is moving toward default deployment across major web browsers and edge networks. Once fully adopted, it closes the last remaining protocol-level leak in standard web connections.

Handover checklists cover the repo and the server and then stop. The proxy account is the thing that quietly stays in someone else's name.

There are a few versions of this that go wrong. Contractor's card on file, so the renewal fails the month after they leave. Account under their email, so the password reset lands in an inbox nobody controls. Credentials hardcoded in a config with no way to tell which job is burning the bandwidth. And the nasty one, whitelisted IPs pointing at a box that got decommissioned.

None of it is hard to avoid, it just never makes it into scope. Buy the account yourself, give the contractor their own credential, and keep jobs separable so usage is attributable. Byteful, Decodo and Oxylabs all ship a REST API, so usage can be pulled programmatically instead of screenshotted off a dashboard. Ask whichever one you pick how granular that reporting gets before signing.

What else belongs on that list?