HTTPS hides the contents of your connection, but for most of the last decade it has still leaked the hostname you’re visiting in plain text via Server Name Indication (SNI). That is the last plaintext field in a modern TLS handshake, and it is exactly the field that ISPs, mobile carriers, national firewalls, and enterprise middleboxes have quietly relied on for years.

On August 27 2026, Google announced that Android 17 ships broad platform support for Encrypted Client Hello (ECH) – calling it the first major mobile OS to do so. It is worth understanding what actually changes and what does not.

What ECH actually does

In a normal TLS 1.3 handshake, the client sends a ClientHello message that includes the hostname it wants to reach. Anyone on the network path can read it, log it, or block on it.

ECH splits that message in two. An outer ClientHello is sent in the clear with a generic, shared “public” name (for example, cloudflare-ech.com). The inner ClientHello – the one carrying the real hostname and the client’s extensions – is encrypted with a public key that the server publishes in DNS via an HTTPS/SVCB record. Only the server can decrypt it. To an observer on the wire, every ECH connection to a given frontend looks the same.

This closes the SNI leak and retires the older, partial “ESNI” experiment in the process.

Where Android stands today

Google’s announcement pairs ECH with Android’s existing Private DNS feature. That pairing is not accidental. ECH is only useful if the DNS lookup that fetches the ECH key is itself encrypted, otherwise the network observer just reads the hostname from the DNS query instead. Private DNS (DNS over TLS system-wide since Android 9, and DoH in the modern resolver) is the enabling piece.

On top of that, Android 17 makes ECH available broadly rather than as a browser-only feature:

  • Chrome for Android has shipped ECH for a while, gated on Secure DNS being on. That still works and now sits inside a wider platform story rather than being the only path.
  • Third-party apps get ECH by upgrading to OkHttp 5.5.0 and enabling it, per Google’s developer guidance. Since OkHttp is the default HTTP client for a very large share of Android apps, that is a realistically broad rollout path.
  • ECH activates only for sites whose operators have published the required DNS records – so the client-side pieces landing does not automatically encrypt SNI for every destination.

What this means for privacy

  1. Carriers and ISPs lose a passive telemetry signal. SNI was one of the last per-connection identifiers they could log at scale. Behind a shared frontend, ECH-protected connections all look the same.
  2. Censorship resistance improves sharply. SNI-based blocking by national firewalls and workplace filters simply stops working. The fallback is IP-level blocking, which is far costlier against a large CDN.
  3. Hostname-based middlebox inspection breaks. Proxies that categorize traffic by hostname without terminating TLS lose visibility, pushing enterprise controls toward the endpoint.
  4. Passive ad and analytics inference gets harder. Anyone profiling users from an SNI stream is now working from a much thinner signal.

What ECH does not fix

ECH raises the floor. It is not a cloak.

  • DNS lookups still happen. If DNS is not encrypted, the hostname leaks there instead. ECH without DoH or DoT is close to pointless.
  • The destination IP is still visible. On a large shared frontend like Cloudflare or Fastly this reveals very little. On a single-tenant IP it still tells an observer where you are going.
  • Traffic analysis and TLS fingerprinting still work. Timing, packet sizes, and client-hello shape can still identify clients and, in some cases, destinations.
  • Anything happening after the handshake is out of scope. ECH is a handshake privacy feature, not an anonymity system.

What this means if you run the server side

If you want Android users to actually get ECH on your service, the server side has to cooperate.

  • Publish an HTTPS/SVCB DNS record carrying your ECH public key and configuration. Clients cannot use ECH without it.
  • Use a fronting name that is shared and generic. Behind a major CDN this is handled for you.
  • If you sit behind Cloudflare, ECH is a toggle. Cloudflare publishes the DNS records, runs the frontend, and rotates keys. Self-hosting ECH is possible with recent OpenSSL, nginx, and HAProxy builds, but it is still fiddly and key-rotation is something you have to own.
  • Keep the rest of your TLS configuration modern – TLS 1.3, HSTS, sensible cipher preferences. ECH is an addition, not a replacement.

Takeaway

ECH on Android is one of the biggest client-side privacy wins since HSTS. It removes the last routine plaintext identifier from a modern web connection and a passive observer cannot work around it. The catch is that all three pieces need to line up – encrypted DNS on the client, ECH in the app or browser, and an HTTPS/SVCB record on the server. Android now delivers all the client-side pieces. The rest is on operators.

Sources