When you connect to an HTTPS site, your browser must tell the server which site it wants — before the encrypted connection is fully set up. That’s because a single IP often hosts hundreds of sites (think Cloudflare-fronted), and the server needs to present the right certificate for the site you’re requesting.

The mechanism: SNI (Server Name Indication). Until recently it was sent in plaintext, leaking which site you were visiting to anyone watching. ECH (Encrypted Client Hello) fixes that. This post explains both, why they matter, and the state of deployment in 2026.

The Problem SNI Solves

In the early days of HTTPS, one IP could host only one HTTPS site. Each TLS connection began with the server presenting its certificate; the client validated it. With one cert per IP, the server didn’t need to know which site you wanted — it served the one site it had.

Then virtual hosting got popular: hundreds of sites on one IP, distinguished by the Host header in HTTP. For HTTP, this worked. For HTTPS, it broke — the server needed to pick a certificate before reading any HTTP, so before knowing which site the client wanted.

SNI is the fix: include the hostname in the first TLS handshake message (the ClientHello). The server reads it, picks the matching certificate, and proceeds.

ClientHello {
    ...
    extensions: [
        server_name: "example.com"
    ]
}

Server reads example.com, presents example.com’s cert. If you’d sent another.com, you’d get another.com’s cert from the same IP.

Why SNI Is a Privacy Issue

The catch: SNI is sent in plaintext. It has to be — the encryption keys aren’t yet established at the start of the TLS handshake.

So any on-path observer (your ISP, the local Wi-Fi, a national firewall, a network operator) can see:

The IP you connected to.
Which hostname you sent in SNI.

Even though the actual HTTP traffic is encrypted, the destination hostname leaks. This is why censorship systems can selectively block specific sites by domain even when the rest of the connection is encrypted.

DNS-over-HTTPS (see DoH vs DoT) closed the DNS-query leak. SNI was the remaining hole.

ECH: Encrypted Client Hello

ECH (formerly ESNI for “Encrypted SNI”) encrypts the SNI inside the TLS handshake itself. The on-path observer can no longer see which hostname you’re connecting to.

The mechanism:

The site publishes an ECH config in a DNS record (an HTTPS record / SVCB record). This includes a public key for ECH.
The client fetches the DNS record (via DoH for true privacy) and learns the ECH public key.
The client encrypts the real ClientHello (including the real SNI) with the ECH public key.
The client sends an outer ClientHello containing a “generic” SNI (the public-facing front-end identity, like cloudflare-ech.com).
The CDN’s front-end (Cloudflare in the example) decrypts the inner ClientHello and routes to the actual destination.

From the outside, all you see is “client connected to Cloudflare, ECH was used.” The actual destination is hidden.

Deployment Status in 2026

ECH has been slowly rolling out:

Cloudflare has supported ECH since 2023 for free-tier customers. Most Cloudflare-fronted sites are ECH-capable.
Firefox and Chrome support ECH and use it when available.
Safari is catching up.
Major CDNs other than Cloudflare have varying levels of support.

In 2026, ECH is real but not universal. Privacy-conscious users get the benefit on Cloudflare-fronted sites; the long tail of self-hosted services usually doesn’t have ECH yet.

Why ECH Helps the Whole Internet

A common question: “I trust my ISP, why do I care about ECH?”

The bigger picture:

Censorship resistance

National-level firewalls that block sites by domain (e.g., the Great Firewall, Iran’s filtering, Russian blocking) rely on SNI inspection. ECH defeats this — they’d have to block entire CDNs (which would break too much) or move to harder techniques.

Aggregation of vulnerable users

Even if you don’t need privacy, supporting ECH on your site protects users who do. Site-by-site adoption matters.

Trust no middlebox

Modern privacy posture is “assume the network is hostile.” ECH is one more layer that makes that assumption credible.

The ECH Config in DNS

The DNS record looks like:

example.com.   IN  HTTPS  1 . alpn="h2,http/1.1" ipv4hint="..." ech="AEX+DQBBKw..."

The ech= field contains the base64 ECH config — public key and acceptable cipher suites for encrypted SNI.

For DNS basics, this is similar to MX or A records — just another DNS record type for ECH config distribution.

What ECH Doesn’t Hide

Even with ECH, some metadata still leaks:

The destination IP is still visible (it’s in the IP header).
Packet size and timing allow traffic analysis (with enough volume).
TLS fingerprint (JA3/JA4) still reveals client characteristics.

For complete metadata hiding, you’d need Tor or a similar onion-routing system. ECH is one important layer, not a magic bullet.

How ECH Affects Application Code

For application developers: ECH is transparent. Your code doesn’t change.

For server operators behind a CDN with ECH:

Your CDN handles ECH automatically.
You don’t manage ECH keys.
Your application code receives plain HTTP requests as usual.

For server operators not behind a CDN:

You’d need to deploy ECH on your TLS terminator (nginx, Caddy support is emerging).
Publish ECH config in DNS.
Most self-hosted services skip this in 2026; the CDN path is easier.

The Front-End / Back-End Hostname

A subtle point: ECH requires a public “front-end” hostname. For Cloudflare, this is something like cloudflare-ech.com. The on-path observer sees “client connecting to cloudflare-ech.com” — generic, doesn’t reveal the actual site.

For private ECH deployments, you’d need to invent a similar front-end identity. CDNs solve this; self-hosters can’t easily without a “decoy” site.

SNI in Logging

For server-side logging:

The SNI is in the TLS handshake; your application sees the requested hostname.
With ECH, your front-end (CDN or proxy) sees both the outer (generic) and inner (real) SNI. The real hostname is what you log.
For most servers, the SNI matches the Host header in HTTP. They should agree.

SNI and Geolocation

A side note on geo features: when your service is behind a CDN with ECH, the request reaching your origin has the CDN’s POP IP, not the user’s. You’re already used to reading CF-Connecting-IP (or equivalent) for the user IP. See X-Forwarded-For header.

ECH doesn’t change this; it’s an SNI-layer protection. Your application logic for geolocation and user identification continues to work the same way.

Browser Behavior

If a site’s DNS includes ECH config, modern browsers use it automatically. If not, they fall back to plaintext SNI. The user sees no difference; the security guarantee differs.

You can verify ECH usage in browser DevTools (Network tab → connection details) or via tools like curl --ech (with curl built with ECH support).

What About QUIC and HTTP/3?

QUIC integrates TLS 1.3, including SNI. ECH applies similarly. Browsers using HTTP/3 to ECH-supporting sites get the same protection.

For more on HTTP/3, see HTTP/2 vs HTTP/3.

TL;DR

SNI lets one IP host many HTTPS sites by including the hostname in the TLS ClientHello.
SNI is plaintext by default — observers see which site you’re connecting to.
ECH encrypts the SNI, hiding the destination hostname from on-path observers.
Cloudflare and major browsers support ECH in 2026; broader adoption growing.
ECH config is published in DNS (HTTPS / SVCB records).
For application developers, ECH is transparent.
For server operators, easiest path is “use a CDN that supports ECH.”
Doesn’t hide everything — destination IP, packet timing, TLS fingerprint still observable.

ECH is the most important TLS privacy improvement of the past few years. It closes a long-standing gap: encrypted traffic with a plaintext destination. For the broader TLS context, see TLS handshake explained; for the related DNS-encryption layer, DNS over HTTPS vs TLS.

SNI and ECH: How TLS Tells Servers Which Site You Want