Firesheep Fix as Easy as HTTPS


November 2010 will be remembered as the month that Firesheep exploded onto the computing scene, much to the delight of college students everywhere. The Firefox browser add-on makes it trivial to gain access to anyone's Facebook account while they're connected to the Internet using an open, unsecured Wi-Fi connection.

Of course, the session hijacking attack vulnerability that Firesheep exploits has been well-known in hacking and security circles for ages – all that Firesheep does is make the attack spectacularly easy. And it's a bit unfair to highlight Facebook as being susceptible to the attack, if only because many other popular sites, including Flickr, Foursquare and Wordpress are just as susceptible to it, too.

But, interestingly, not Gmail. That's because Google, unlike these other sites, made the decision some time ago to enable secure SSL connections between its email servers and users' browsers all the time, by default. By contrast Facebook, Flickr and these other sites only use SSL during the authentication phase of a visit to the site, dropping down to plain, insecure HTTP connections for the rest of the session.

On the face of it there's a good reason for Facebook and company to use unsecured connections: SSL involves public key crypto, which is hugely computationally intensive. Using SSL all the time would require either racks of special SSL-processing hardware or vast amounts of regular processing resources, in order to cope with the demands of millions of users. That would make it financially very expensive, and therefore impractical for sites, such as Facebook.

Except that this is all a complete load of old poppycock – it's an urban myth right up there with the one about getting a free Tootsie Roll if you send in a wrapper with an Native American boy shooting an arrow at a star or the Nieman Marcus cookie recipe. If it wasn't poppycock, then how on earth would Google, even with all its mighty resources, be able to cope with the mountain of SSL traffic that Gmail generates?

Confirmation that it's a myth comes, rather handily, from Google, in the form of a blog post by Adam Langley, a senior software engineer at the company. "If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive anymore," he writes. "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...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."

You can't get much more emphatic than that, can you?

The reason that no additional machines and no special hardware are required is largely due to the way SSL has evolved. Ten years ago, each time you contacted a server using an SSL connection – for example to request a new Web page – the whole SSL certificate checking and public key crypto routine had to be carried out, and there is no question that this routine was computationally expensive. But these days, SSL has the ability to resume a previous SSL session, which, put simply, means that you only have to go through the whole SSL process once, and from then on the SSL connection is virtually computationally "free."

Now here's the thing. If you're offering an application, such as Facebook or Flickr, or any sort of corporate Web app that requires authentication, you still have to set up an SSL connection while customers authenticate themselves with their usernames and passwords, even if you drop down to an unsecured connection afterwards.

The key point is that once you have authenticated your customer, the SSL heavy-lifting has been done. So after that, you may as well continue using an SSL connection, as Langley makes clear. "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."

So it's pretty obvious why Google can afford to "SSLize" Gmail then: not because it has vast data centers and bottomless pits of money, but because it is not actually a very expensive wheeze to pull off. And using some of the tricks that Langley highlights in his blog posting, it doesn't have to have a significant impact on performance either.

That means you and everyone else have a right to expect that Facebook, Flickr et al will secure your accounts from Firesheep (and other malicious session hacking tools) using SSL—and there's little doubt that very soon they will do exactly that. Enterprises that offer Web applications to employees or customers will have to follow suit, as well.

Going forward it also means that any other Web applications you access, whether for business or personal reasons, should use SSL connections exclusively. If they don't, you should demand to know why not. And avoid them.

Paul Rubens is a journalist based in Marlow on Thames, England. He has been programming, tinkering and generally sitting in front of computer screens since his first encounter with a DEC PDP-11 in 1979.

Keep up with browser security news. Follow eSecurityPlanet on Twitter: @eSecurityP.