Android 17 cannot hide an app’s destination by itself

Android 17 network privacy

Prove the connection, not the version number

Encrypted Client Hello removes one important hostname leak only when DNS, the app library and the server complete the same contract.

1. Platform support is not packet evidenceAndroid 17 provides ECH policy and APIs, but the app’s networking library must adopt them and the server must accept the encrypted inner hello.
2. DNS supplies the encryption configurationAn HTTPS or SVCB record can carry the public ECH configuration before the TLS connection begins.
3. ECH narrows metadata exposureIt can conceal SNI and other sensitive ClientHello fields; it does not conceal the destination IP address, packet timing or traffic volume.
4. A privacy claim needs four receiptsRecord resolver transport, the HTTPS record, client-library behavior and server acceptance for the same app, hostname and test moment.

Android 17 introduces platform support for Encrypted Client Hello, or ECH. Google describes the change as a way to hide the domain names that supported apps and websites expose to network operators. That description is directionally correct, but it is easy to turn it into a broader claim than the implementation can prove.

An operating-system upgrade does not rewrite every application’s network stack, publish a server key in DNS or make every TLS endpoint accept an encrypted ClientHello. Android now supplies the policy surface and low-level APIs. The observable privacy result still belongs to a chain with owners on both sides of the connection.

The phone can support ECH while the app still sends visible SNI

In ordinary TLS 1.3, most of the handshake becomes encrypted after the connection starts, but the original ClientHello historically exposed the Server Name Indication. SNI tells a shared server which hostname the client wants. It also gives a passive observer a useful piece of browsing metadata even when the page content is protected by HTTPS.

ECH divides that message into an outer and inner hello. The outer message is safe to expose and carries an encrypted inner message; the inner message contains the real SNI and other connection preferences. This is a protocol capability, not a guarantee that every Android connection uses it. Android’s own behavior-change documentation says ECH is active only when the networking library has integrated support and the remote server supports the protocol.

Deployment contract

Four independently owned facts must agree

“Runs on Android 17” proves only one part of the path. A connection-level claim needs evidence from the resolver, platform policy, client implementation and server.

DNSConfiguration existsThe HTTPS record carries an ECH public configuration for the target service.

PlatformPolicy permits ECHAndroid 17 returns a domain-encryption mode for this hostname.

ClientThe library uses the APIsThe networking stack retrieves and passes the configuration before TLS starts.

ServerThe inner hello is acceptedThe endpoint decrypts ECH instead of completing only the public outer path.

The HTTPS record has to arrive before the private hello

The client cannot encrypt its inner hello until it knows the server’s ECH public configuration. RFC 9848 defines how DNS SVCB and HTTPS resource records carry that configuration. Android 17 adds the corresponding DnsResolver capability so a networking library can request the HTTPS record before starting TLS.

This order is not cosmetic. The RFC says an ECH-capable client must not issue the TLS ClientHello until SVCB resolution has completed when it is relying on the DNS record. A stale, missing or inconsistent record changes the connection path before Android’s socket APIs have anything useful to encrypt.

Before TLS

Resolve the service and obtain the ECH configuration

The DNS answer binds an encryption public key and metadata to a client-facing server. All advertised addresses must reach servers that can use the corresponding private key or connections can fail.

At TLS

Build a public outer hello around a private inner hello

The app library passes the configuration into the platform TLS implementation. The server then accepts ECH, supplies a retry configuration or proceeds on the outer path according to the protocol and policy.

The order matters

DNS is not a preliminary optimization here. It supplies the material required to form the encrypted hello.

Enabled is a policy state, not proof of use

Android 17 adds <domainEncryption> to Network Security Configuration. The default is enabled for apps whose networking library supports ECH, while an app can disable the behavior globally or for selected domains. The platform also exposes NetworkSecurityPolicy.getDomainEncryptionMode() so a custom library can check the effective rule before querying for a configuration.

<network-security-config>
  <base-config>
    <domainEncryption mode="enabled"/>
  </base-config>
  <domain-config>
    <domain includeSubdomains="true">legacy.example</domain>
    <domainEncryption mode="disabled"/>
  </domain-config>
</network-security-config>

The XML expresses intent. It does not prove that an older or custom HTTP client queried the HTTPS record, passed an EchConfigList to SSLSocket or SSLEngine, and observed server acceptance. Google’s adoption guide therefore begins with the networking library, not with the manifest. Its August guidance specifically tells developers to use a library version with Android ECH support.

Build an ECH adoption receipt for one real hostname

The practical audit unit is not “our Android app.” It is one app build, one networking path and one hostname. A WebView can follow a different release cadence from an embedded custom client. A first-party API can publish ECH correctly while an analytics or authentication host does not. The receipt below keeps those claims from collapsing into a single yes-or-no checkbox.

ECH adoption receipt

One hostname, four dated proofs

Record the same app build and test moment across every line. If one line is missing, report capability or intent—not verified destination privacy.

ResolverWas the hostname query protected between device and resolver?Evidence: Private DNS or another authenticated encrypted transport, resolver and timestamp.

HTTPS recordDid the answer contain a usable ECH configuration for every selected endpoint?Evidence: full RRSet, TTL, target names and configuration identifiers.

ClientDid this exact library build attempt ECH for the hostname?Evidence: library version, effective domain-encryption mode and a controlled connection trace.

ServerWas the encrypted inner hello accepted rather than merely greased?Evidence: test endpoint or server-side signal that distinguishes acceptance from randomized GREASE.

Allowed claim

“ECH was accepted for this tested connection.” Do not silently widen it to every host, every app surface or permanent anonymity.

GREASE makes this distinction essential. When a client lacks a usable configuration or the server does not accept ECH, it can send an extension with randomized contents. That behavior makes non-support harder to fingerprint, but the fake extension does not encrypt the real SNI. Seeing an ECH-shaped field is therefore not the same as proving that the inner hello was protected.

ECH hides the hostname, not the physics of the connection

RFC 9849 protects SNI and other sensitive fields inside ClientHello. RFC 9848 is equally explicit about the boundary. The DNS lookup can reveal the name if transport to the resolver is not encrypted. The destination IP address remains visible on the network. Timing, packet size, retry behavior and the size of the server’s anonymity set can still support inference.

ECH can conceal

The requested hostname inside TLS setup

SNI, selected application protocols and other sensitive inner ClientHello fields no longer need to travel as plaintext.

The network still observes

Where packets go and how they behave

IP addresses, timing, volume, interruptions and a resolver’s own view remain outside the narrow protocol promise.

Privacy improves by shrinking a leak

ECH is valuable precisely because it removes a high-signal hostname field. It should not be marketed as a VPN, traffic-obfuscation layer or proof that no party can infer the destination.

This narrow reading matches a broader Android pattern. The platform can enforce an accessibility privilege boundary, but the product still has to justify its purpose. Likewise, Chrome can turn notification permission into a renewable relationship, but a historical grant does not prove current entitlement. Security states become useful only when they are tied to the event they claim to control.

Questions about Android 17 and Encrypted Client Hello

Official Android and protocol sources

Official materials checked 1 September 2026

1. Android Developers: Adopting Encrypted Client Hello — app and library integration steps, policy modes and platform APIs.
2. Android Developers: Network security configuration — the domainEncryption contract and its library-support boundary.
3. Android 17 behavior changes — targeting requirements, integrated networking libraries and server support.
4. RFC 9849: TLS Encrypted Client Hello — inner/outer ClientHello, acceptance, retry and GREASE behavior.
5. RFC 9848: Bootstrapping ECH with DNS Service Bindings — HTTPS/SVCB delivery, fallback and remaining metadata boundaries.
6. Google Security Blog: Android 17 network protections — public launch context and developer adoption guidance.