The topic of data security is becoming increasingly important for both private users as well as in the business world. As a website owner, you should take all the necessary precautions to ensure that a visit to your site is as secure as possible. Converting your site from HTTP to HTTPS or SSL is an important first step to securing your website and gaining your customers’ trust.
Security plays a big role on the internet. As a result, there are standards, certificates, and protocols that try to protect users as well as servers from malicious attacks. One of these protocols is called Transport Layer Security (TLS). Since this system is problematic, however, server name indication (SNI) serves as an extension.
Why is server name indication needed?
Before you can understand why SNI was developed, you first need to understand how TLS works. The successor of the Secure Sockets Layer (SSL) uses a so-called TLS handshake. This is where the client and the server - in practice, this usually means the web browser and the website - exchange information before beginning the actual data transfer. With this virtual handshake, the server identifies itself to the client and sends the corresponding security certificate. Once the client has verified this, both communication partners receive the connection and exchange data. If the verification comes back negative, then no further data transfer takes place.
But what happens when multiple websites run on a single IP address, as with virtual hosting? Since IPv6 has not yet fully established itself, we have to work with a very limited IP address range and not every domain can claim its own IP address. So to whom does the client address its “Hello” (the first step of a TLS handshake)? There’s a high probability that the wrong website responds, an incorrect certificate - with the correct host name - is sent, and the connection is not established. This is why it’s necessary for the client to share with the server the domain (host) with which they would like to establish a connection. For this purpose, the server name indication was introduced.
If there’s a discrepancy in the certificates (the name of the requested website doesn’t agree with the name on the certificate), then the client terminates the transfer. The reason for this is that such an inconsistency can represent a major security risk in the form of a man-in-the-middle attack.
How does SNI work?
If an unsecured connection causes multiple websites to run over one IP address, you usually don’t have to deal with this problem. HTTP designates that the host name is given in a header when a website is requested. With TLS, though, the handshake must have taken place before the web browser can send any information at all. Server name indication takes care that the host name is already transmitted between the server and client before the certificate exchange.
SNI is an extension of TLS. The encryption protocol is part of the TCP/IP protocol stack. As such, TLS extends the Transmission Control Protocol (TCP) with an encryption. The additional layer also converts HTTP to HTTPS. If you extend TLS with server name indication, then the handshake adds another field to the security protocol: under ClientHelloExtension, there’s an optional ServerName field. Here, the client enters the name of the host (the web browser does this automatically) that they want to address. This ensures that the correct host answers.
Server name indication in the browser
As an ordinary user, you shouldn’t have to come into contact with the process of SNI. In most cases, users don’t even need to install or set up anything for it. Using a current operating system and modern browser is perfectly sufficient. Firefox, Chrome, Edge, Opera, and Safari all support the extension by default. For some users who still use Windows XP (or even older Windows versions) and its Internet Explorer, server name indication isn’t available. Even if you’re still using an operating system that’s no longer supported by updates, you do have the option to install another browser that supports SNI. Most mobile browsers also use SNI.
Server: IIS, Nginx & Apache with SNI
If you yourself are the operator of a web server, the situation is different because you may have to take action - depending on which web server you use: since IIS 8, Microsoft has integrated an option for server name indication into its software by default. The Apache HTTP server looks a bit different. Here, it’s possible to use OpenSSL (or mod_ssl) to integrate SNI. Basically, you just have to run the module with TLS extensions (which is already preset from version 0.9.8k). An exact manual on setting up SNI with Apache can be found on the Apache HTTP Server Wiki.
Nginx also has in-house SNI support since Version 0.5.23 and essentially functions just like Apache. You can check whether your version supports server name indication with the command nginx -V. If it does, then as the webmaster you have to give each virtual host its own name and assign it the correct certificate. Find more information about this in the official Nginx documentation.
If your website still doesn’t offer encryption, learn how to convert your website to HTTPS in our guide.
What are the drawbacks of SNI?
Server name indication isn’t all benefits. For example, SNI isn’t supported by all web browsers - although this admittedly only effects a small number of users. The fact that SNI is not a perfect model, (it’s more of a simple transfer solution) can be seen in the way information is transmitted unencrypted. True, the only information is the host name, but this information could be protected from third-party attacks with even basic encryption. It would be more secure if you didn’t have to use SNI and instead each website had its own IP address.
Since this can’t be changed due to the tight IP address range (at least until IPv6 is implemented globally), other options have to be found. One of these options is SNI. Another would be Subject Alternative Name certificates (SAN): with these certificates, you have the option of entering multiple domains or hostnames. This would mean, by implication, that it doesn’t matter to the server which domain the client actually wants to address since the certificate is valid for all domains on the server. The downside of these certificates, however, is that they’re comparatively expensive. It’s understandable, then, that many website operators aren’t ready to implement such certificates. Instead of using absolutely no encryption at all, SNI is a good interim solution.