Server Name Indication (SNI)

Server Name Indication (SNI) solves an impossible timing problem in TLS.

When you connect to an HTTPS server, the TLS handshake happens first—before any HTTP data is sent. During this handshake, the server must present a certificate to prove its identity. But here's the problem: if the server hosts multiple sites (example.com, another-site.org, third-domain.net), which certificate should it present?

The server must choose a certificate before knowing who you're asking for—like being asked to hand someone their mail before they tell you their name.

Before SNI: One IP, One Site

Without SNI, the only information available during the handshake was the IP address being connected to. So each HTTPS site needed its own unique IP address. The server could identify the site by the IP, then present the matching certificate.

This worked, but IPv4 addresses are finite and increasingly expensive. Requiring a dedicated IP for every HTTPS site made secure hosting impractical for most websites.

The SNI Solution

SNI adds one piece of information to the TLS handshake: the client includes the hostname it wants in the initial ClientHello message.

The connection now works like this:

1. Client connects to the server's IP address
2. In the ClientHello, client includes "I want example.com"
3. Server reads this, selects example.com's certificate
4. Handshake continues with the correct certificate

Now thousands of HTTPS sites can share a single IP address. The server knows which certificate to present because the client tells it upfront.

The Privacy Trade-Off

Here's what SNI reveals: we built TLS to hide what we're saying, but SNI announces where we're going in plaintext.

The hostname travels unencrypted in the ClientHello. Anyone watching the connection—your ISP, a corporate firewall, a government—can see exactly which site you're visiting. They can't read your messages to that site, but they know you're talking to it.

This matters:

• Censorship systems block sites by reading SNI
• Network monitoring tracks which sites users visit
• ISPs can log browsing patterns based on SNI alone

You might assume HTTPS hides everything. It doesn't. The destination is visible even when the conversation isn't.

Encrypted Client Hello (ECH)

ECH fixes the privacy problem by encrypting the hostname.

The client fetches a public key from DNS, encrypts the SNI and other sensitive handshake data, and sends it encrypted. Now network observers see only the IP address, not the specific hostname.

ECH is rolling out gradually—Firefox has experimental support, Chrome is implementing it, and server adoption is growing. When fully deployed, it closes the privacy gap that SNI opened.

Configuring SNI

Modern web servers handle SNI automatically. You configure each site with its hostname and certificate:

Nginx:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/example.com.crt;
    ssl_certificate_key /path/to/example.com.key;
}

server {
    listen 443 ssl;
    server_name another-site.com;
    ssl_certificate /path/to/another-site.com.crt;
    ssl_certificate_key /path/to/another-site.com.key;
}

Apache:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /path/to/example.com.crt
    SSLCertificateKeyFile /path/to/example.com.key
</VirtualHost>

<VirtualHost *:443>
    ServerName another-site.com
    SSLEngine on
    SSLCertificateFile /path/to/another-site.com.crt
    SSLCertificateKeyFile /path/to/another-site.com.key
</VirtualHost>

The server reads SNI from incoming connections and selects the matching configuration block.

Configure a default certificate (usually the first server block) for clients that don't send SNI or request unrecognized hostnames.

Testing SNI

Verify your configuration with OpenSSL:

openssl s_client -connect example.com:443 -servername example.com

The -servername flag sends SNI. Test the same IP with different hostnames—each should return its own certificate:

openssl s_client -connect 192.168.1.100:443 -servername site1.com
openssl s_client -connect 192.168.1.100:443 -servername site2.com

Compatibility

SNI support is universal in anything built in the last decade. Every modern browser, operating system, and HTTP library handles it automatically.

The only clients that lack SNI are genuinely ancient: Windows XP with Internet Explorer 6-8, Android 2.2 and earlier. These represent a vanishingly small percentage of traffic and have far larger security problems than SNI support.

For practical purposes, you can assume SNI works everywhere.