Server Name Indication (SNI) and virtual hosting

Virtual hosting is concept of serving multiple domains from the same IP address.

So you can have both wip.co and mommyshomecooking.com being server from the same server (without any fancy virtualization).

But serving multiple domains behind the same IP has it’s challenges, and SNI tries to solve some part of it.

There’s a lot that goes into maintaining a multi-tenant architecture like this. I do not go into detail about that here, but this video does a good job explaining the concept in further detail

SNI stands for server name indication. This abbrevation made me think that SNI was directly tied to the server, but boy was I naive!

So firstly, SNI is not some proxy/server configuration (which I initially thought it was). It is an extension inside SSL

And another fun fact I recently understood was that there is also a TLS server. This is created to work along with your backend service and takes care of the SSL connections.

A few things to get upto speed:

1. Remember, SSL connections work on top of the TCP layer of the network stack.
2. In most cases SSL certificates are bound to the domain for which you are serving the request

So the TLS server is where we configure the server name or SNI, because one problem with virtual hosting is mixing up the certificates being served while handling the requests for the different domains.

You see, without SNI, if you try to configure different domains on the same server, then you will not have any way of identifying which SSL certificate to be served.

How does the client indicate the server name?

So okay, SNI gives the server context to choose the certificate to be used for SSL

Note: here I am only talking about the client using SSL over HTTP. In the real world, SSL is used to secure many other application layer protocols like SMTP and FTPS (which is FTP secured with SSL).

For the SSL/TLS part of the request, the SNI is passed by the client in the client hello during the TLS handshake.

But if there are mutliple domains on the server, how does the client communicate which domain it is talking to in the subsequent HTTP (actually TCP) requests? Remember, client makes the request to the server only denoting the IP of the server, which it got from a DNS lookup.

I used to think DNS is where the domain name was no longer relevant, since all further communications happen using IP addresses.

HTTP has a special header for this — The Host header. You might have seen this while inspecting the HTTP request headers inside chrome debugger network tab

Virtual Hosting is now so ubiquitous that the host header is a mandatory header since the HTTP/1.1 spec.

A little more about the Host header.

You can happily walk away from this post now with a better understanding of how serving several domains from one IP really works.

But if you have a tendency of going into rabbit holes while learning something (like me!), let’s clear a few confusions I had with the Host header

1. Is it only useful in case of virtual hosting?

Clearly not. CDNs and other kinds of reverse proxies that work on Layer 7, use the Host header to make routing decisions and service discovery. CDNs also sometimes use it to define caching rules.

2. How is it different from the Origin Header

The Origin header, although not visible in the network tab in the chrome debugger, is sent for every request made by your browser.

If you ever manage to see the request after it leaves the browser, you will see that in many cases the value of the Origin header and the Host header are almost the same.

Not knowing their actual purpose, I used to assume that these can be used interchangeably in some cases 🤦‍♂️

But the origin, value of the origin header, denotes information (scheme, host, and port) of the web page that initiates the request

The Host header, as we discussed, is instead used to denote the destination for where request was intended to be sent.

---

That's all for today. Hope this helps, see on your next request!