Introduction
Virtual Hosting is the practice of serving multiple websites on the same server. Although it is the norm nowadays, this was not possible in the early days of HTTP (versions before 1.1).
Originally, a server could only host multiple websites on the same machine (i.e. under the same IP address) provided that each website was assigned a dedicated port. This was not an ideal solution because browsers default to port 80 for HTTP, unless the user specifies a different one. As a result, most website owners opted for a dedicated server to avoid the risk of users not remembering the correct port number and ending up on a different website.
Nevertheless, as more users joined the Web and more network devices began appearing online, the number of available IP addresses started to decrease at an alarming rate. This anticipated depletion, known as IPv4 address range exhaustion, has driven the industry to design and implement various counter-measures, such as IPv6 (IPv4’s successor), which can support more addresses than we will ever need. Unfortunately, although IPv6 is a viable solution, its adoption has been quite slow. According to Google’s IPv6 statistics, at the time of this writing just about 25% of Internet devices are deployed over IPv6.
Virtual hosting was also implemented as an early mitigation to the exhaustion problem, with the introduction of the Host header in HTTP 1.1. Browsers communicating over HTTP 1.1 were now able to connect to a server’s port 80 and include the domain name (e.g. www.ssl.com) of the website they wanted to visit in the Host header. Regardless of how many sites a server hosted on the same port, it could use this information to identify the correct website and return its content.
HTTPS and Virtual Hosting
Numerous published reports on network vulnerabilities and attacks against web users, however, have motivated the industry to start moving away from insecure HTTP, to its more secure alternative HTTPS. The wide adoption of HTTPS has improved overall user security. However, its additional enhancements have also increased the general complexity of web communications.
In principle, HTTPS is quite similar to HTTP, with the exception that HTTPS communications between browsers and servers are encrypted. Briefly, HTTPS requires servers to provide browsers with a valid SSL certificate issued by a publicly trusted certificate authority (CA), such as SSL.com. A browser can then use the public key contained in the certificate to establish an encrypted communications channel with the server. Furthermore, a certificate is issued for a specific domain name, which the browser checks for a match with the domain the user wanted to visit. Thus, no matter how many websites the server hosts, browsers expect to find a valid SSL certificate for the website they have requested.
The attentive reader might already sense the problem: the browser requires the correct website’s certificate in order to establish the encrypted channel and send the Host header, while the server needs the Host header to locate the correct site’s certificate. This is a classic chicken-and-egg problem.
It is apparent that virtual hosting as it was conceived for HTTP does not work for HTTPS, because the security controls prevent browsers from sending the Host information over to the server. Nonetheless, with the IPv4 exhaustion problem still unresolved, and the industry’s ever-increasing adoption of cloud technologies (that require load-balancing and multiple fail-over backend servers), virtual hosting is still a necessity.
What About Multi-Domain Certificates?
A proposed solution to this problem is the use of multi-domain or SAN certificates. A single SAN certificate can secure hundreds of different domain names, and browsers will not complain if they find the domain name they are trying to visit inside the SAN certificate’s domain list. After the encrypted channel is configured, the browser can send the Host header to the server and continue on as in any other case. This is a great idea that utilizes a technology already present and available, but the same mechanisms that ensure the security of SAN certificates have also introduced a few potentially undesirable side-effects:
SAN certificates are a fine tool for securing multiple domains owned by the same entity (person, company or organization), but they are somewhat impractical to use in shared hosting; whenever a new domain is ready to be added to or removed from the certificate, a new certificate with the latest list of domains must be issued by the CA, and redeployed on all domains.
Furthermore, SAN certificates can only be issued as Organization Validated (OV) or Extended Validated (EV) if all domains belong to the same organization. These validation levels refer to the amount and types of the prospective certificate owner’s information verified by the CA before issuing them the certificate. It has been shown that the higher the validation level is, the more trust users place in the website, and user trust can affect brand recognition and conversion rates.
Finally, it is quite common in shared web hosting environments for a company to share a server with other businesses or organizations (even with its competitors). Since the domains in SAN certificates are publicly listed, business owners might be reluctant to share the same certificate with third-party companies.
Although SAN certificates are powerful and versatile tools with countless applications, these issues have motivated IETF – the governing body for Internet standards – to search for better-fitted approaches to the specific problem of virtually hosted HTTPS websites.
Server Name Indication to the Rescue
The solution was implemented in the form of the Server Name Indication (SNI) extension of the TLS protocol (the part of HTTPS that deals with encryption).
SNI enables browsers to specify the domain name they want to connect to during the TLS handshake (the initial certificate negotiation with the server). As a consequence, websites can use their own SSL certificates while still hosted on a shared IP address and port, because HTTPS servers can use the SNI information to identify the appropriate certificate chain required to establish the connection.
Afterwards, when the encrypted communications channel has been configured, the browser can proceed to include the domain name of the website in the Host header and continue as it normally would. Essentially, SNI performs the same function as HTTP’s Host header during the creation of the encrypted connection.
This simple trick finally allowed servers to host multiple HTTPS websites on the same port. However, as with most Internet technologies, SNI has some limitations.
SNI Support Concerns
Although SNI is quite mature since it was first drafted in 1999, there are still a few legacy browsers (IE on Windows XP) and operating systems (Android versions <=2.3) that do not support it. For a comprehensive list of browsers and operating systems that support SNI, please take a look at this table.
Although the market shares of browsers that do not support SNI (and by extension the occurrences of this happening) are minuscule when compared to modern browsers, if a browser does not recognize SNI it will fall back to the default SSL certificate, and potentially produce a common name mismatch error.
Many companies, such as Google, implement SNI for the clients that support it, and fall back to SAN certificates for the rare cases that do not. Naturally, this issue is expected to diminish as more and more users and business owners upgrade their systems to modern technologies.
SNI Privacy Concerns
The current stable version of TLS (version 1.2) transmits the initial part of the handshake, and by extension SNI information, unencrypted. Consequently, a network attacker can discover a user’s web history, despite the web communications themselves being fully encrypted.
Various cloud service providers, such as Amazon or Google, have allowed a (dirty) workaround known as domain fronting. Domain fronting can prevent the disclosure of web history because it obfuscates SNI information by using the cloud provider’s hostname in the TLS negotiation and the target site’s in the HTTP header. However, this method is not viable anymore, since Google and Amazon have publicly stated that they disabled support for domain fronting in their services as of April of 2018.
Fortunately, a more systemic solution has been proposed as an experimental draft detailing the Encrypted SNI (ESNI) extension for the newest TLS version, 1.3. ESNI encrypts SNI information, thus mitigating all privacy concerns. Unfortunately, TLS 1.3 isn’t widely adopted by the industry yet, even though TLS 1.3 is slowly becoming the de facto network security protocol. Keep an eye out for future articles from us about the status of ESNI and privacy of HTTPS and TLS.
Conclusion
In summary, with SNI you can host millions of HTTPS websites on a single server. However, depending on your individual case, a SAN certificate might work better for you. The privacy concerns about SNI still exist, though there also exists a potential solution with ESNI. In any case, using one or a combination of these two methods, you can easily implement virtual hosting for all your websites with minimal effort.
If you have more questions about SNI or don’t know how to choose between SANs and SNI, we are always happy to answer all our customers’ questions about their PKI needs. Just drop us an email at support@ssl.com and an expert will help you.