The encryption problem
In the early days of the Internet, there was very little encrypted traffic. People simply trusted that nobody was out to get them. But later on, security and encryption became an important part of online life.
Historically, when a web browser made a connection it would resolve the IP address of the required web server and make a connection to that IP address on the desired port. The issue here was that you could only run a single site on a given IP address and port combination, and if you wanted to run multiple sites you had to either use multiple IP addresses or different ports for each site. This was extremely inefficient, and IP addresses cost money as well as being difficult to obtain (there’s also a lack of IPv4 addresses, but that’s a different story).
Evolution is a wonderful thing. For a number of years, web (HTTP) servers have been able to offer multiple sites from a single machine using ‘vhosts’, where you offer the name of the site you want and are presented the appropriate content. Performed at the HTTP protocol level, this has provided a new world of flexibility in terms of resource utilization and ease of management, as sysadmins only need to maintain a few servers to provide many, many websites.
Layer limitations
As the Internet continues to grow, so do the potential dangers of communicating important information. Gone are the ‘good old days’ where there was an implicit level of trust between users, and as a result of this, there has been a significant uptake in the requirement to secure data transmission online.
The encryption layer was awesome, protecting users and companies alike. But it had no way of knowing which site name you wanted to use - it just saw a connection on port 443 and offered the SSL certificate it was configured with. One way around this particular behavior was to have an SSL certificate that matched all the domain names in your organization (commonly identified as a wildcard certificate in the form *.mydomain.com), or there was the option to use a SAN (Subject Alternative Name) certificate with all your site names listed. This was often undesirable, though, as you would expose all the sites you were hosting when someone accessed a single site, and a SAN certificate was limited to five FQDNs (Fully Qualified Domain Names) which is still quite restrictive.
A secure solution
So how do we get multiple secure services on a single IP address and port? The answer is Server Name Indication, or SNI. With SNI the browser, in the initial SSL conversation, advises which site (by name) it wants to access. The server then presents just the required certificate and website content.
SNI to the rescue
The server that hosts www.penguins.site also hosts www.kittens.site, and several other sites too. Without SNI you could have the following scenario: The server that hosts www.penguins.site also hosts www.kittens.site, and several other sites too.
- User types in the address bar https://www.penguins.site/
- Browser resolves this to IP address 1.2.3.4
- Browser initiates an SSL connection to 1.2.3.4 on port 443 (for https) requesting www.penguins.site
- Server offers the SSL certificate for www.kittens.site
- Browser displays a warning screen to the user, who may accept or reject the connection
- If the user rejects, nothing further happens, but they may never re-visit.
- If the user accepts:
- Browser makes HTTP get request through the SSL tunnel for www.penguins.site
- Server provides site content
This scenario is what we would prefer to avoid. SNI to the rescue!
With SNI configured on the server end, the conversation goes a little more like this:
- User types in the address bar https://www.penguins.site/
- Browser resolves this to IP address 1.2.3.4
- Browser initiates an SSL connection to 1.2.3.4 on port 443 (for https) requesting www.penguins.site
- Server offers the SSL certificate for www.penguins.site
- Browser makes HTTP get request through the SSL tunnel for www.penguins.site
- Server provides site content
SNI in the Loadbalancer.org product
The load balancer splits the traffic flow into layers: SSL decryption, which includes SNI functionality; and Layer7 service.
Within the “Cluster Configuration” → “SSL Termination” menu you can define the behavior of each termination, including the SNI entries. If you don’t already have an SNI entry defined for a given termination you should click “Modify” and select “Yes” against the menu entry “Use Server Name Indication (SNI)”. This will expose a further menu where you can define the SNI entries. Each entry has a friendly name, which is just how you can reference it on-screen; after you’ve set this name, you can choose the “SNI to match”, which is the part that the client (web browser, email client, etc) uses to request the appropriate SSL certificate (as above).
As of v8.3.7, you have the ability to provide a ‘wildcard’ as part of the “SNI to match”, meaning you could have “*.mydomain.com” defined on the Loadbalancer.org appliance - so you could match mydomain.com, www.mydomain.com, mail.mydomain.com or anythingyoulike.mydomain.com all on a single termination. Of course, your SSL certificate needs to match, or else you’ll have client end warnings.
Next up, you’ll choose the SSL certificate to offer if the SNI is matched, followed by the “Associated Virtual Service” which is the L7 VIP that you’ll pass the traffic to. Selecting this will enable a rule within the L7 configuration that will pass the connecting client’s IP address through to the L7 service so that it can, if applicable, pass it forward in the connection chain (more on this in a future blog). As an alternative you can set this to “Custom” and provide the details of IP address and port, which doesn’t have to be a virtual service on the load balancer, but normally is.
Summary
SNI can be used to distinguish between required services based upon the client requesting the server name. This isn’t limited to HTTP services - it also works with services such as IMAP, LDAP and SMTP. As we have effectively run out of IP addresses this means we can continue to add new encrypted services to the internet without needing to use non-standard ports or have SSL exceptions. Of course, this means that the client machine needs to be “new enough” (see here for details) but this shouldn’t be a major roadblock as it’s been supported for many years on most client software.