The Background
Transport Layer Security (TLS), or formerly Secure Sockets Layer (SSL), is a protocol to establish a securely encrypted channel for many other higher level communication protocols. In particular, when combined with HTTP, the bundle is widely known as the HTTPS protocol. One important feature of HTTP is the “name-based virtual hosting”. In which the “host” header is used to allow multiple websites with different hostnames to be served from the same web server with the same IP address and port number. However, the initial versions of SSL broke this feature for HTTPS. Because during the SSL handshaking, the server needs to present a certificate to the client for verification. If a server is hosting multiple websites, during the SSL handshaking stage, it has no idea about which one the current request is trying to access. So it has no choice but presenting one generic certificate to all clients.
There have been two old solutions to support virtual hosting for HTTPS. One is to make sure that generic certificate supports all the hostnames the server is hosting. The second one is to assign a dedicated IP address to each certificate. Both created significant problems to CDN providers, who use the same set of servers to serve thousands of customer domains. The first solution requires the CDN provider to put the hostnames of many different customers into the same SAN certificate. Whenever this certificate is to be updated to add or remove a hostname for one customer, all of the customers on it will be notified by the certificate authority (CA) to confirm the update. This can be a hassle for customers. Also for performance and security issues, only limited number of hostnames can be put in a single certificate. Most CAs recommend less than 100, which makes this solution not scalable. The second solution requires a dedicated public IP address on each PoP for each certificate, and they collectively form a dedicated service map for each certificate. With the IPv4 address being more and more scarce these days, those service maps for non-SNI domains usually have much fewer PoPs comparing to those of the SNI counterparts. The maintenance of the numerous dedicated service maps also means more complicated system, lower degree of automation and self-service.
Server Name Indication (SNI) was introduced in 2003 as an extension to the TLS 1.0 protocol to provide a graceful solution to this problem. The idea is very simple, the client just send the intended hostname to the server in the first data packet (ClientHello) of the TLS handshaking. When the server sees this hostname, it will pick the right certificate to present to the client, instead of some generic one. SNI nicely enabled the virtual hosting for HTTPS websites. For CDN providers, it means we can again use the same set of servers and IP addresses to serve multiple domains from multiple customers. As we mentioned earlier, the SNI service maps usually contain much more PoPs, which means better service performance to the end users. Other benefits to our customers include lower price and better self service of TLS certificates on the portal.
The Plan
Therefore, QUANTIL is starting a plan to phase out the non-SNI provisioning of TLS certificates. Any new contract signed on or after April 1, 2018 will be SNI only. Existing customers currently using non-SNI provisioning will be contacted by the account executives to discuss the migration to SNI. Any contract renewed on or after July 1, 2018 will be SNI only. We expect that by July 15, 2019, all domains using non-SNI provisioning will be moved to SNI.
The Trade-off?
A natural question to ask is: What will be the impact to the end users? Is there any downside with SNI? Here is the answer.
Since SNI is relatively new (only 15 years old in this rapid-pacing world of internet:)), it is not supported by ALL browsers or HTTP clients. Wikipedia has a nice article with some technical details of SNI and applications that do not support it. This is a nice website to test the capability of your HTTP client, including the support of SNI. The most significant clients that do not support SNI today is the MSIE browsers on Windows XP. We have run some analysis on some typical domains that are still using non-SNI on our platform. We found that in China, where is believed to have the highest Windows XP retention rate, only 0.9% requests were made from Windows XP. Out of those requests, close to 90% were made from Chrome or Firefox browsers which do support SNI. Therefore only less than 0.1% of all clients are not supporting SNI. We believe it is a worthwhile movement to SNI to provide better service to the 99.9% of end users and to drive the 0.1% to move to more secure operating systems and web browsers.
There is also a possibility that some apps or bots written with some old libraries, such as Java1.6, PHP5.2 or Go1.3, do not support SNI. In that case, we strongly suggest you to update the apps or bots with some newer library to get the latest security features and, of course, SNI support.
Bin Ni is the VP of Engineering of QUANTIL. He and his team is working on all technical aspects of all QUANTIL products.