SNI: Telling the Server Which Site You Want

SNI (Server Name Indication) is a field in the client's first TLS message that names the site it wants to reach. A single server, or a single IP address at a CDN, often hosts thousands of sites, each with its own certificate, and it must pick the right one before encryption begins, since the certificate is part of setting up encryption. SNI tells it which.

Picture a hosting provider with one address, 203.0.113.10, serving both shop.example.com and blog.example.org. A browser connects to that address. Without SNI, the server would have to guess which certificate to present, and one of the two sites would always fail with a wrong-name error.

The server reads the name, picks the matching certificate and continues. A client that sends no SNI gets a default certificate, which is why old clients and some scripts see a wrong-name error from a server that works in a browser. With openssl s_client, the -servername option sends it.

SNI has a privacy cost. Because it travels before encryption starts, anyone on the path can read which site a user is visiting, even though the path and content are hidden. Networks use this to filter or block sites by name, and it is why HTTPS hides what you do on a site but not, usually, which site it is.

Encrypted Client Hello (ECH) is the fix. The client encrypts its real ClientHello, including the name, with a key the server publishes in DNS, and sends an outer hello naming only a shared front, such as the CDN. Support is arriving in major browsers and some CDNs, but it is not yet universal, so in most connections today SNI is still readable.

So when a server returns the wrong certificate, check whether the client sent the right name; and when asking what a network observer learns from HTTPS, include the site name.