Should our .Edu Sites Be Using SSL by Default?

Written by Mike on March 19, 2012

I recently read this blog post by Google announcing they are beginning to roll our secure searching to their sites around the world. They say:

Several months ago we made a change to our default search experience on google.com — when you’re signed into Google, we add SSL encryption to increase the privacy and security of your web searches. The change encrypts your search queries and our search results page, which is particularly important when you’re using an open, unsecured Internet connection.

With Twitter and Facebook also starting to go SSL by default, it got me thinking. Is it time for our .edu websites to go all SSL? We currently encrypt some areas, but making all our webpages be secure, whether they are collecting data or not, may be something to start considering.

I think it would show some credibility to users, and would add an additional layer of protection for forms that currently aren’t secure, such as event registration, feedback forms and surveys. Yes, some this data is not the most sensitive, but it’s always better to be safe than sorry[1].

Implementing SSL on a site is trivial, and not terribly expensive. NameCheap.com offers SSL certificiates starting at $9 USD a year and going up from there. That small cost, even at $125 USD per year, is worth the piece of mind.

Will adding SSL give your website a performance hit? This used to be the case, but not as much anymore. It’s nothing that can’t be offset by a little  optimization on the developer end. Even something as simple as GZIP’ing and minifying your CSS and javascripts may balance out any (perceived) hit in performance due to SSL. Adam Langley of Google writes this about SSL performance:

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. 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.

As a test, we’ve been using SSL in our WordPress admin areas. I haven’t noticed any difference in performance, and it was a good first step in rolling it out site wide (which at this point would be just checking a box.)

[1] If you have bad code, forms or not, on your website, it won’t matter if you have the best security in the world. Bad code is bad code.