Secure Site Hosting
Illustration by Kevin Kennedy, strazi.org
While most websites do not need to be served from a secure connection (i.e. "https://www.example.com"), it is appropriate in some cases. From a hosting and server perspective, there are several ways to go about hosting a secure site. We've tried them all and Sitemason® has chosen to only offer the absolute best method of providing secure sites, which is not the cheapest method, but it is by far the most redundant, scalable, and optimized method, which makes for a superior end product.
Basic Terms and Issues
What is a secure website anyway, you may ask? We're not going to get terribly technical here (but will link to a few choice Wikipedia pages for those who are curious), but basically it's a method by which communication between the server (your website) and the end user's computer is encrypted. This means, if someone else were to be spying on the packets of data flowing through your network, they could see the data, but not be able to do anything constructive (or destructive, in that case) with it because it's encrypted. That might sound a bit unnerving, so you may next ask, why isn't every website secure? There is overhead in encrypting the data (it's slower and harder on the servers) and, in the vast majority of the cases, it doesn't matter - the information is publicly-available on your website anyway. The reality is, you should really only care that you're using a secure connection if sensitive information is being transferred.
Now it's time to get a bit more technical, but it's important. To facilitate the encryption, a secure certificate is required, which is a key pair that is used to encrypt your website's traffic. When someone comes to https://www.example.com (note the "s" in https - they want to call your site securely), the server needs to know which private key to use in order to handle the encryption. In good old fashioned SSL, the traffic just appears to the server on port 443 (the default port for https). The server doesn't know what website it is being asked to serve-up. Assuming there is more than one website on the server, unless you want to send out a URL like "https://www.example.com:10314/give-me-money" (note the odd port, which exudes a rather suspicious vibe, doesn't it?), we must accept this postulate:
Every website using a secure certificate must be bound to one IP address.
Now let's dig into the various ways to implement secure site hosting.
Bare-Bones Secure Website
In this case, www.example.com points to an IP address, which in turn points to one server which handles the encryption for secure traffic for your website. Our secure postulate is covered in this implementation, since there is only one website on this server. But, when this server fails, your site is down.
Usually the server is hosting more than just your website - it's probably hosting many websites and has multiple IP addresses pointing to it. However, regardless of the load placed on this server, when it fails, your site fails too.
We do not like this method at Sitemason, therefore we do not offer this solution as an option.
Basic Shared-Hosting Secure Website
Eventually everyone realized that the one-IP-address-per-secure-site requirement was not ideal and a new solution was created. That solution is called Server Name Indication, or "SNI" for short. Under SNI, the visitor's browser tells the server, "I want to see www.example.com securely!" and the server selects www.example.com's secure certificate, then serves up the site securely. In this case, there are definitely multiple secure websites being served from a single server (or a pool of servers, which would at least allow for some load balancing).
On the surface, SNI sounds like a great solution and it's also cheap and easy to implement, because from a shared hosting perspective, not much changes at all! However:
- Windows XP does not support SNI
- Internet Explorer 6 does not support SNI
- A handful of other older browsers do not support SNI
Despite the fact that these browsers and operating systems are over a decade old, there are a TON of people still using Windows XP and/or Internet Explorer 6.0, especially in business environments. It's a sad fact, but it is a true one. When someone using an unsupported browser or operating system visits your secure site running via SNI, they'll get a big scary security warning. No one likes security warnings and neither do we, so we do not offer SNI as an option.
Advanced Load-Balanced Secure Websites
In this case, each secure certificate gets assigned to a dedicated load balancer to handle the encryption. Since the load balancer is only used for the one secure certificate (and thus the one website), older browsers are perfectly happy with it. Also, since it's a load balancer, it routes traffic to many servers across multiple secure networks, providing exceptional availability.
All Sitemason websites use this technology and our shared secure server (secure.sitemason.com) uses it too. Until recently, sites requiring their own secure certificate were forced to compromise with one of the other solutions mentioned. However, now every Sitemason website needing its own secure certificate can have all of the benefits of the absolute best solution too.
Running a dedicated load balancer is not trivial - there is additional expense, plus we must monitor and maintain it to ensure that everything is working properly. It is therefore neither the cheapest, nor the easiest solution for hosting websites that need their own secure certificate. However, it is by far the best approach. This is the only way Sitemason hosts secure websites.