The hostname you visit over HTTPS is sent in plain text
HTTPS encrypts data but not the site name, which travels in clear text via the SNI extension. This article explains the mechanics, why it’s necessary, and how ECH can hide the hostname, though adoption remains limited.
When you visit a site over HTTPS, the traffic inside the tunnel is encrypted, but the address you’re asking for is not. The Server Name Indication, or SNI, is a part of the TLS handshake that tells the server which certificate to present, and it is sent in plain text at the very start of every HTTPS connection.
How the SNI Works
Every HTTPS connection begins with a TLS ClientHello message. In that message, the client includes an extension called server_name. The extension is structured as a length‑prefixed string that contains the hostname. For example, a ClientHello to secret.wikipedia.example looks like this in hex:
- 01 00 00 d7 03 03 ... 73 65 63 72 65 74 2e 77 69 6b 69 70 65 64 69 61 2e 65 78 61 6d 70 6c 65
The ASCII bytes starting at 0x73 spell out the hostname. No encryption or hashing is applied, so anyone who can see the first packet of the connection can read the site name.
Why the Hostname Is Sent Unencrypted
Modern servers host thousands of sites on a single IP address. Before the server can send back the correct certificate, it must know which site the client wants. The SNI solves this chicken‑and‑egg problem by putting the hostname in the ClientHello, which is sent before any keys exist. Because the handshake must start in clear text, the SNI remains unencrypted for the lifetime of the TLS protocol.
Passive Observation Is Easy
A passive listener can read the SNI without decrypting any traffic. A simple 15‑line Python server that accepts a connection, reads the first packet, and extracts the hostname demonstrates this. The listener never completes the handshake or obtains a private key, yet it can log every domain a client requests.
Corporate proxies, national firewalls, and ISPs can use this technique to filter traffic by domain without breaking encryption. The content of the connection stays private, but the destination is exposed.
TLS 1.3 Does Not Fix the Problem
TLS 1.3 encrypts more of the handshake than TLS 1.2, including the server’s certificate. However, the ClientHello—including the SNI—remains in the clear because it is sent before any keys are negotiated. A listener can still read the hostname from a TLS 1.3 connection.
Encrypted Client Hello (ECH) Is the Proposed Solution
ECH moves the hostname out of the TLS handshake and into DNS. The server publishes a public key in a DNS HTTPS record. The client retrieves this key before connecting and encrypts the entire ClientHello, including the hostname, inside an outer packet that carries only a generic cover name. From the network’s perspective, every ECH‑protected connection looks the same.
For example, Cloudflare publishes an ECH configuration for crypto.cloudflare.com with a public key and a decoy name cloudflare-ech.com. A client that supports ECH will send a ClientHello that appears to be for cloudflare-ech.com, but the real hostname is hidden inside the encrypted payload.
Current Adoption and Limitations
OpenSSL 3.5 does not yet support ECH, so many clients cannot use it. Even when a site publishes an ECH record, the domain that hosts the ECH configuration may not. For instance, cloudflare.com itself does not publish an ECH record, while crypto.cloudflare.com does. Moreover, ECH only protects the hostname if DNS queries are also encrypted. If the client’s DNS traffic is unencrypted, a passive observer can still read the hostname from the DNS request.
How to Check If a Site Uses ECH
You can query a site’s DNS HTTPS record for an ech field:
curl -s -H "Accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=crypto.cloudflare.com&type=HTTPS" | grep -o 'ech=[A-Za-z0-9+/=]*'
If the response contains an ech blob, the site supports ECH. Otherwise, the hostname will still be exposed.
What This Means for Your Privacy
While HTTPS keeps the contents of your connection private, the destination is still visible to anyone who can see the first packet. Until ECH is widely deployed and DNS is encrypted, network observers can always know which sites you visit, even if they cannot read the traffic itself.
To protect your browsing destination, you can use a VPN or a DNS‑over‑HTTPS (DoH) client, but these solutions only add layers; they do not replace the need for ECH to hide the hostname at the TLS level.
In short, the encryption in HTTPS works as intended for data confidentiality, but the SNI remains a privacy gap that ECH aims to close. Adoption is still patchy, and without encrypted DNS, ECH offers limited protection.
Why it matters
Knowing that the hostname is exposed helps users and organizations understand the limits of HTTPS privacy and motivates the adoption of ECH and encrypted DNS to truly hide browsing destinations.
Key points
- HTTPS encrypts data but not the site name, which travels in plain text via the SNI.
- A passive listener can read the hostname from the first packet of any TLS connection.
- TLS 1.3 does not change this; the ClientHello remains unencrypted.
- Encrypted Client Hello (ECH) hides the hostname by encrypting the ClientHello and using a DNS‑published key.
- Adoption of ECH is limited and requires encrypted DNS to be effective.
- Users can check if a site supports ECH by querying its DNS HTTPS record.
Frequently asked questions
What is the Server Name Indication (SNI)?
SNI is a TLS extension that carries the hostname a client wants to connect to, allowing servers to present the correct certificate when multiple sites share an IP address.
Does TLS 1.3 hide the hostname?
No. While TLS 1.3 encrypts more of the handshake, the ClientHello—including the SNI—remains in clear text.
How does Encrypted Client Hello (ECH) work?
ECH encrypts the entire ClientHello, including the hostname, using a public key published in a DNS HTTPS record. The network sees only a generic cover name.
Is ECH widely supported?
Support is still emerging. Many clients and servers do not yet implement ECH, and even when it is available, it requires encrypted DNS to be fully effective.
