Understanding The Need For SNI…

Connections in HTTP:

  • Information travels in an unencrypted form.
    • Plain-text.
  • The server recognizes the site to which the client wants to connect by reading the value of the Request Header: “Host”.
Host: siteA.net

Host: siteB.net

Standard HTTPS Connection 🔒️

  • In HTTPS, the information is encrypted!
    • The data, including request headers, is encrypted.
    • The server does not have access to the ‘Host’ request header.
  • We must remember that the server needs to return a certificate to complete the TLS Handshake.
  • When information is encrypted, we only have access up to Layer 4. The server will make a decision based on information present at Layer 3: Packet IP.
  • The only information the server has to decide which certificate to return to complete the TLS Handshake is the “Destination Address” in the IP Packet.
  • IP Packet Structure:
0                   1                   2                   3  
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+  
|Version|  IHL  |Type of Service|         Total Length           |  
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+  
|        Identification         |Flags|      Fragment Offset     |  
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+  
|   Time to Live  | Protocol    |        Header Checksum         |  
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+  
|                         Source Address                         |  
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+  
|                      Destination Address                       |  
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+  
|                    Options and Padding (if any)                |  
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+  
|                             Data                               |  
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+  
  • This makes it impossible for a server to host multiple HTTPS pages on the same IP address.
    • Why?
      • An IP address can only have one certificate associated with it. Thus, if the server only knows that the client wants to connect to ‘10.10.10.10’ (Destination Address), the server returns the certificate associated with that IP.
  • A single IP address cannot have more than one certificate associated with it.
  • If the server only has one HTTPS site, there’s no issue. However, if it has multiple HTTPS sites, how does the server know which certificate to return to complete the TLS Handshake?
  • There are only two ways to host multiple HTTPS sites on the same server:
    1. Associate each page with a different IP address, since a certificate is linked to an IP address.
    2. Serve HTTPS pages on the same IP address but on different ports (e.g., HTTPS 10.10.10.10:443, HTTPS 10.10.10.10:4443, etc.):
    1. However, clients must know in advance the port on which the site is published…

Traditional Certificate Configuration At The Server Level

  • The certificate is associated with a unique IP:Port combination.
  • 1:1 relation.
    • An IP:Port combination can only have one certificate associated with it.
  • To see the certificates associated with HTTP.SYS on a Windows Server using IIS as the server:
netsh http show sslcert 
  • Notice how the certificate with an ending thumbprint of “58804” is attached to the IP address “0.0.0.0” on port 443.
    • You simply cannot have two certificates attached to “0.0.0.0:443”.

What Is SNI?

  • Defined in RFC 6066 - TLS Extensions
  • SNI is an extension of the TLS protocol that allows the client to indicate, within the Client Hello, the hostname of the site it wants to connect to.
  • The hostname is found in the field called ‘server_name.’
  • This information is not encrypted, so the server can read the hostname of the site the client wishes to connect to and, in this way, serve the corresponding certificate.
  • Both the client and the server must support SNI.
  • At the server level, the certificate is linked to a hostname.
  • IPv4 and IPv6 addresses are not yet allowed as values for the hostname within SNI.
  • If the server understands the extension in the Client Hello but does not recognize the value of ‘server_name,’ the server has two options:

  • And of course there is the third option where the server does recognize the “host_name” and it simply proceeds and uses the TLS certificate attached to that hostname.
  • When a certificate is attached to a combination of “hostname” and port, this is SNI, and you can use the same command as before (netsh http show sslcert):
    • Notice how now the certificate ending in thumbprint “58804” is a attached to a hostname of “cert3.com” on port 443.

In Summary

  • SNI is an extension of the TLS protocol that allows the client to indicate, within the Client Hello, the hostname of the site to which it wants to connect.
  • Both the client and the server must support SNI.
  • Normally, the configuration of a certificate at the server level is associated with a unique IP:Port combination.
    • Only one certificate can exist for each unique IP:Port combination.
  • With SNI, at the server level, the certificate is now mapped to a combination of hostname:port.