HTTPS Tradeoffs

Posted by Aaron Massey on 21 Mar 2011.

Ars Technica has a great article about HTTPS by Scott Gilbertson. He mentions Firesheep:

Web security got a shot in the arm last year when the FireSheep network sniffing tool made it easy for anyone to capture your current session’s log-in cookie insecure networks—your local coffeeshop’s hotspot or public WiFi at the library. That prompted a number of large sites to begin offering encrypted versions of their services via HTTPS connections.

This validates Eric Butler’s creation of Firesheep. (And it provides further validation for a lot of arguments in favor of full disclosure in security…)

More interestingly, the article describes the security tradeoffs in a way that even non-technical people will be able to understand:

The real problem, according to Lafon, is that with HTTPS you lose the ability to cache. “Not really an issue when servers and clients are in the same region (meaning continent),” writes Lafon in an e-mail to Webmonkey, “but people in Australia (for example) love when something can be cached and served without a huge response time.”

Lafon also notes that there’s another small performance hit when using HTTPS, since “the SSL initial key exchange adds to the latency.” In other words, a purely security-focused, HTTPS-only Web would, with today’s technology, be slower.

I know a lot of folks that don’t understand why their favorite sites aren’t encrypted by default. The answer is that there’s a real tradeoff involved. On one hand, you have some arguments against using SSL:

Acquiring an SSL certificate has a cost.
Latency has a cost.
Not being able to cache data has a cost.
A higher processing power requirement has a cost.
Not being able to use virtual hosting has a cost.

On the other hand, you have some arguments in favor of using SSL:

Users need secure passwords.
Users need privacy in their personal information.
Users need assurance againts phishing.

What is the “value” of these things? How do you calculate a cost for them? It’s easy to sit back and say, “Sure, why not? Of course these companies should be using SSL!” However, it may not really be a completely trivial question. For companies that don’t need to protect passwords and don’t deal in personal information, maybe the tradeoffs aren’t worth it. For companies that do, then maybe they are. Personally, I believe it makes solid business sense to respect your customers enough to protect them. I would imagine most users feel the same way.