ASVS 5.0 V12.1.5 requires Encrypted Client Hello (ECH) to be enabled in your TLS settings, so metadata such as the Server Name Indication (SNI) is not exposed in clear text during the handshake. It is a Level 3 requirement.
Without ECH, anyone on the path can read which hostname a client is connecting to, even though the traffic itself is encrypted.
Why it matters
For most sites the hostname is not secret. For some it is: a clinic, a legal service, an internal admin hostname, a whistleblower portal. Hiding the SNI removes a data point for network surveillance and censorship.
How to implement it
ECH is a two sided feature, and support depends on your stack and your clients.
- Choose a TLS library or edge service with ECH support and a current version.
- Generate an ECH key and config and publish the public config in a DNS HTTPS record for your domain.
- Keep a public "outer" name that clients present in the clear, and run the real service behind it.
- Rotate the ECH keys on a schedule and keep the previous key briefly so cached DNS records still work.
Because support varies by server software, check your vendor documentation for the exact switch. Do not paste unverified config from forum posts.
How to test it
dig +short HTTPS example.com
The record should contain an ech= parameter. Then capture a handshake from a client with ECH support and confirm the inner hostname is absent from the ClientHello in a packet capture.
Common mistakes
- Publishing the DNS record but running a server that cannot decrypt the inner hello, which breaks connections.
- Leaking the name elsewhere, for example through plain DNS queries. Pair ECH with encrypted DNS on the client side.
- Treating ECH as a replacement for access control.
Quick check
Does ECH hide the IP address?
No. It hides the requested hostname. The destination IP remains visible, so shared hosting helps.
