Detailed Explanation of SNI Extension in HTTPS and Virtual Host HTTPS Configuration

Detailed Explanation of SNI Extension in HTTPS and Virtual Host HTTPS Configuration

1. Background Knowledge

In traditional HTTP/1.1, Virtual Host is implemented through the Host field in the HTTP request header, meaning multiple domain names can be hosted on a single IP address + port. The server routes the request to the corresponding website based on the Host field.
However, when establishing a TLS connection for HTTPS, the TLS handshake must be completed first to establish an encrypted channel before the HTTP request (containing the Host header) can be sent. This creates a contradiction:

  • The server needs to provide the certificate for the corresponding domain during the TLS handshake phase, but it doesn't yet know which domain the client wants to access (because the Host header hasn't been sent), causing the server to be unable to decide which certificate to use.

To solve this problem, the SNI (Server Name Indication) extension was introduced to the TLS protocol.

2. Role and Working Principle of SNI

SNI is a TLS extension (defined in RFC 6066) that allows the client to send the domain name it intends to access in plaintext within the ClientHello message of the TLS handshake.
This way, the server can see the domain name early in the handshake and select the correct certificate to return to the client.

SNI Workflow

  1. Client initiates TLS handshake
    Sends a ClientHello message containing:
    • Supported TLS versions, cipher suite list
    • SNI extension (containing the domain name to access, e.g., www.example.com)
  2. Server receives ClientHello
    Parses the SNI extension to obtain the domain name.
  3. Server selects certificate
    Finds the corresponding SSL/TLS certificate based on the domain name.
  4. Server returns certificate
    Sends the certificate for that domain in the ServerHello and subsequent Certificate messages.
  5. Subsequent handshake
    Same as a regular TLS handshake (key exchange, completing the handshake, etc.).

Note: The domain name in SNI is transmitted in plaintext (because the handshake is not yet encrypted), meaning network eavesdroppers can see the domain name the client is accessing, but the subsequent communication content remains encrypted.

3. Compatibility and Limitations of SNI

  • Browser/Client Support: Modern browsers, operating systems, and HTTP client libraries (e.g., curl, requests) support SNI by default.
  • Server Support: Mainstream web servers (Nginx, Apache, Caddy, etc.) support SNI.
  • Limitations:
    • Early systems (e.g., Windows XP + IE6) do not support SNI and will fail to access multi-domain HTTPS sites.
    • Some network monitoring devices may filter or block based on SNI information (e.g., firewall domain-based blocking).

4. Virtual Host HTTPS Configuration Example (Nginx)

Assume a server IP is 192.168.1.1 and needs to host two HTTPS sites:

  • www.site1.com (certificate file: site1.crt; private key: site1.key)
  • www.site2.com (certificate file: site2.crt; private key: site2.key)

Nginx Configuration Snippet:

server {
    listen 443 ssl;
    server_name www.site1.com;
    
    ssl_certificate     /path/to/site1.crt;
    ssl_certificate_key /path/to/site1.key;
    
    # Other configurations...
}

server {
    listen 443 ssl;
    server_name www.site2.com;
    
    ssl_certificate     /path/to/site2.crt;
    ssl_certificate_key /path/to/site2.key;
    
    # Other configurations...
}

Principle: When Nginx receives a TLS handshake request, it obtains the domain name via SNI, matches the server_name, and uses the corresponding certificate.

5. Alternative Solutions Without SNI

If support for legacy clients that do not support SNI is mandatory, traditional solutions include:

  • Use a separate IP address for each domain name (each IP configures one HTTPS site).
  • Use a multi-domain certificate (SAN certificate) or wildcard certificate, covering all domain names in a single certificate (the server can return the same certificate without relying on SNI selection).

However, both solutions have limitations (limited IP addresses, complex certificate management), making SNI the mainstream solution.

6. Security Enhancement for SNI: Encrypted SNI (ESNI) / ECH

Because SNI is in plaintext, it exposes the domain names users visit, posing a privacy risk.
ESNI (called ECH, Encrypted Client Hello, in TLS 1.3) encrypts the entire ClientHello (including SNI), so only the target server can decrypt it.
This technology requires DNS HTTPS records (HTTPS RR) or server configuration support and is currently in the gradual promotion phase.

7. Common Interview Questions

  1. Why does HTTPS virtual host need SNI?
    Answer: The TLS handshake occurs before the HTTP request. The server needs to return the correct certificate during the handshake phase but cannot determine the domain via the Host header at that point. Therefore, the client must declare the domain name in advance via SNI in the ClientHello.

  2. Does SNI cause privacy leakage?
    Answer: Yes, SNI is in plaintext. This can be addressed via ESNI/ECH.

  3. How to check if a website supports SNI?
    Answer: Use openssl s_client -connect host:443 -servername example.com to observe if the returned certificate's domain name matches, or check the TLS handshake details via the browser's developer tools.

Through the steps above, you can understand the core role of SNI in HTTPS virtual hosts, along with its configuration, limitations, and evolution direction.