Recently, I was forced to challenge a long-held notion about SSL: that the overhead was so significant that it ought to be used sparingly. I had held this belief for a long time, dating back to the preteen years of the web. The idea was that SSL caused a large increase in both CPU and network usage, so it should be used only on pages that dealt with sensitive information. I think I first learned this rule back when I didn’t need to shave regularly and I was heavily into Pearl Jam.
Well, it’s now 2013, last I checked. I look pretty bad if I go a couple days without shaving. I still hold Pearl Jam in high regard, but grunge has certainly declined in popularity.
CPUs have become a lot more powerful, and bandwidth has increased from those dialup years. Speaking of dialup, does anyone miss the sound of those old modems? I don’t. So when it came time to setup SSL on a new site we were deploying, a colleague (admittedly, a bit younger than I) brought up the idea that we might consider site-wide SSL. My first reaction was "No way, the overhead will kill us." He pointed me to a few articles and white papers, raising the point that google did it, so why should’t we? I guess it was time for me to challenge my old beliefs and take another look at it. As an aside, my purpose here is not to convince anyone whether to use SSL or not, it’s simply to prompt a re-evaluation of how sparingly SSL should be used on your sites.
- Server CPU Usage and Network Latency (translation: it’s slower)
I’m not going to try and provide proof and data to dispel this one. There are plenty of blogs and whitepapers that a quick googling will reveal. I will simply say that these seem to be relics of the past. Hardware has progressed to the point that these are fairly negligible. Not to say that there isn’t increased server load and latency when using ssl, but the significance is minimal. To summarize what gmail engineer Adam Langely said:
On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.
Here are a couple of other links that I found particularly insightful:
https://www.eff.org/https-everywhere/deploying-https
http://research.zscaler.com/2010/11/why-web-has-not-switched-to-ssl-only.html
http://arstechnica.com/business/2011/03/https-is-great-here-is-why-everyone-needs-to-use-it-so-ars-can-too/ - Requires more work to setup the server properly
There’s no doubt that a little extra work is needed to effectively make use of site-wide SSL. The most obvious is the generation of the certificate itself. But, hey, you’re probably going to do this part anyway. And although this step might seem a little intimidating at first, it’s really quite simple. It’s a one time thing, costs relatively little, and once it is setup, it can be forgotten about. So this is really not much of a concern. There are some other best practices to consider when designing a site that will use site-wide SSL, and I’ll talk about those in a future post. - Subject to mixed mode warnings
Everyone has seen those mixed mode warnings, especially if you use IE ;). This happens as a result of something on your page being requested over an insecure channel. This might be an image, a stylesheet, or a javascript file. Rule #2 of SSL usage is that every dependency for a page has to also be requested via SSL, otherwise the whole page is vulnerable. This obviously can cause problems for sites who rely heavily on 3rd party content, ads, or CDNs that don’t support SSL. In this case, site-wide SSL might not be the right choice for you. Generally, it’s just a matter of requesting your scripts, stylesheets, and images using the https protocol. This is a fairly simple change for a developer to make, and gets rid of those ugly broken locks or alerts.
Armed with this new information and a fresh perspective, we decide to roll out site-wide SSL on our site. To be honest, the transition was easy. In fact, it was easier than rolling out page specific SSL, since we never had to worry about redirecting back and forth to secure and non-secure pages. We simply added a middleware that forced SSL redirection. We were already using relative urls in our app, so no change was needed there. And finally, we changed requests for page dependencies to us SSL as well. I’m happy to say that, to date, we haven’t had any measurable speed decreases since rolling this out. Our pageload times have held relatively constant and our error rates have stayed low. Best of all, our visitors are reassured by the twinkling little lock icon in their browser – a beacon of hope in a fallen world.
So increasing security without much of a cost was a real win in my book. After all, I don’t think too many people would be upset if the internet became a more secure place.
