Posts
However, what I didn't talk about is whether this is true for companies. A single security breach in a single user account maybe doesn't cost a company much, but if breaches get common enough that they start losing users, it could be a problem with a much higher cost.
While users trying to protect themselves from curious folk with firesheep are counseled to use a VPN, website owners can choose to do encryption right from their end using SSL. But it was thought that SSL was computationally costly and even environmentally costly due to the supposed need for extra electricity and machines.
But who's been looking at what those costs actually are? A blog post entitled Overclocking SSL looked at the severity of these costs as they deployed SSL, and made a pretty clear statement:
If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users.
So there you have it: the people who should be protecting users from firesheep attacks are probably the companies who run the websites, since SSL isn't likely to be as costly to them as numerous complaints and support requests would be from their users. The cost equation might not be the same for all organizations, since the cost of certificates and labour can be non-trivial if you don't already have expertise on hand. But sure enough, Google has decided to provide https access by default to all gmail users, so they clearly believe it's worth it.
This leads to an interesting question: Does the burden of security always fall heavily on corporations and large organizations rather than on end-users? Many would argue that this is naive and that users must bear some responsibility, others would argue that only corporations have the resources necessary to make an impact on security. This is a much larger discussion that I expect we'll see occurring over and over again for a very long time.
3 comments:
I discussed this with Andrew who has talked about the launchpad.net trade-offs a bit, and his summary was: no the computational effort isn't significant now, but SSL negotiations add noticeably to round trips costs (especially impacting people who are not physically close to the server, so, usually not something North Americans notice most prominently in their web experience), which can be mitigated but not without a fair investment of developer time.
Did you get a chance to read through the Overclocking SSL post? They actually spent quite a lot of time working on addressing the problem of round trip time, and I realise what little I quoted might have misled you into believing that they hadn't.
(This doesn't change the fact that this is a problem that affects some users more than others, of course.)
I suspect for some open source organisations and other groups with limited budgets, the certificate costs can be pretty prohibitive too. When John was looking into it for kernel.org, he was getting quotes well over USD $50k because they needed *.*.kernel.org to handle the various wikis and git repositories and such that they host. Even with * certificates so they wouldn't have to buy a new cert for every new project, it was pretty ridiculous. Self-signing is becoming non-viable for usability reasons thanks to Firefox. In the end, Kernel.org was fortunate enough to get a donation from a signing authority to solve their encryption problem.
So yeah, it's definitely not like SSL is the answer for everyone, but it's important to make the decision based on actual problems and not imagined computational costs that aren't nearly as high as they were once reported to be.
Thanks, I've now Read the Whole Thing and as you say it is good on the subject. I do like to see an explicit acknowledgement of the disproportionate impacts of adding round trips, but you can't have everything.
Post a Comment