Server Name Indication (SNI) in IIS


Server Name Indication (SNI) in IIS

Server Name Indication is a TLS extension to IIS 8+ that allows for additional functionality to include a virtual domain as a part of the SSL negotiation. This means that when a visitor requests content over the secure port that instead of being bound to the IP address to then utilize the hostname, the hostname itself is the identifier. This allows for multiple hostnames to use the same IP address and the secure port bound to the hostname can then successfully establish.

The level of scalability is very attractive to our clients that are using their Windows Dedicated Servers to host multiple domains that need to have their visitors accessing a secure HTTPS instance of the sites. With SNI available, they no longer need to purchase static IP addresses for each domain in order to have a secured website. This was previously a requirement in older versions of IIS as the web server was incapable of including the hostname identification in the SSL negotiation. SNI is also very useful for our shared hosting clients who are needing to host domains across our shared server infrastructure and allows them to save the cost of a dedicated IP address for wanting to have a secure site instance.

Note: IIS 8+ does require that the server is running Windows Server 2012 or 2016 and is not available for Windows 2008. If you were on the fence about upgrading or Dedicated Server to use Windows Server 2012 or 2016, SNI is a very solid reason to consider making the move. Having a SNI supported Dedicated Server will also allow you to make use of the Let’s Encrypt module which can provide temporary SSL’s for your client domains.

More information regarding Let’s Encrypt can be found below:

How Does It Work?

SNI is an extension of TLS (The encryption protocol is part of the TCP/IP protocol stack.) TLS is also responsible for adding the additional layer also converts HTTP to HTTPS. When you extend TLS with server name indication, then the handshake adds another field to the security protocol: under ClientHello (to which the server loads the available extensions) there’s an optional ServerName field. Here, the browser enters the name of the host automatically that they want to address. This ensures that the correct host answers. The server then corresponds with the correct hostname to complete the secure connection by answering the hostname request over the secure port binding that has been configured for that hostname.

Drawbacks Of Using SNI

The biggest drawback to utilizing SNI is that not all browsers can support the extension. Older browsers are incapable of handling a secure connection using SNI and will fail to provide the hostname during the ClientHello request in the TLS extension. This will leave the server unable to accept the hostname and will likely attempt to secure the connection using the first available SSL certificate regardless of hostname since it does actually know what to try an secure.

Another issue is that the SNI connection is not “entirely” secure. The ClientHello actually sends the hostname without encryption. Largely because the Server doesn’t exactly know to secure the request at first. This is promptly addressed by the server when the hostname is given, but in the interim that data is exposed though not necessarily sensitive.

For individuals that find this a little too unsettling, a suitable alternative would be to utilize a Subject Alternative Name certificate (SAN). These certificates can cover all domains on a server instance regardless of the hostname being utilized. The obvious downside to the use of this certificate is cost. SAN certificates are expensive compared to the use of SNI which is built into the web server by default.