What is the Server Name In­di­ca­tion (SNI)?

Security plays a big role on the internet. As a result, there are standards, cer­tifi­cates, 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 prob­lem­at­ic, however, server name in­di­ca­tion (SNI) serves as an extension.

Before you can un­der­stand why SNI was developed, you first need to un­der­stand 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 in­for­ma­tion before beginning the actual data transfer. With this virtual handshake, the server iden­ti­fies itself to the client and sends the cor­re­spond­ing security cer­tifi­cate. Once the client has verified this, both com­mu­ni­ca­tion partners receive the con­nec­tion and exchange data. If the ver­i­fi­ca­tion 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 es­tab­lished 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 prob­a­bil­i­ty that the wrong website responds, an incorrect cer­tifi­cate - with the correct host name - is sent, and the con­nec­tion is not es­tab­lished. 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 con­nec­tion. For this purpose, the server name in­di­ca­tion was in­tro­duced.

If an unsecured con­nec­tion causes multiple websites to run over one IP address, you usually don’t have to deal with this problem. HTTP des­ig­nates 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 in­for­ma­tion at all. Server name in­di­ca­tion takes care that the host name is already trans­mit­ted between the server and client before the cer­tifi­cate exchange.

SNI is an extension of TLS. The en­cryp­tion protocol is part of the TCP/IP protocol stack. As such, TLS extends the Trans­mis­sion Control Protocol (TCP) with an en­cryp­tion. The ad­di­tion­al layer also converts HTTP to HTTPS. If you extend TLS with server name in­di­ca­tion, then the handshake adds another field to the security protocol: under Clien­tHel­loEx­ten­sion, there’s an optional Server­Name field. Here, the client enters the name of the host (the web browser does this au­to­mat­i­cal­ly) that they want to address. This ensures that the correct host answers.

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 suf­fi­cient. 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 in­di­ca­tion 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 name in­di­ca­tion isn’t all benefits. For example, SNI isn’t supported by all web browsers - although this ad­mit­ted­ly 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 in­for­ma­tion is trans­mit­ted un­en­crypt­ed. True, the only in­for­ma­tion is the host name, but this in­for­ma­tion could be protected from third-party attacks with even basic en­cryp­tion. 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 im­ple­ment­ed globally), other options have to be found. One of these options is SNI. Another would be Subject Al­ter­na­tive Name cer­tifi­cates (SAN): with these cer­tifi­cates, you have the option of entering multiple domains or hostnames. This would mean, by im­pli­ca­tion, that it doesn’t matter to the server which domain the client actually wants to address since the cer­tifi­cate is valid for all domains on the server. The downside of these cer­tifi­cates, however, is that they’re com­par­a­tive­ly expensive. It’s un­der­stand­able, then, that many website operators aren’t ready to implement such cer­tifi­cates. Instead of using ab­solute­ly no en­cryp­tion at all, SNI is a good interim solution.