A lot of Web sites use cookies to store authentication information. You'll log in via an HTTPS connection, but then revert to HTTP when you've authenticated. Then the cookie — with your authentication information — is sent over plain HTTP. This is no big deal when you're on your home network (assuming you trust all the people in your home, of course, and you use WEP or WPA for your Wi-Fi). But if you're in a coffee shop, at a conference, or using some other public network then sending your cookies over HTTP makes it easy for someone else to hijack your session.
Understanding Firesheep
Firesheep makes it really easy. There's been a lot of press about Firesheep, and some of it gives the impression that HTTP hijacking is a new development or suddenly made possible by Firesheep. It's not new, but the tools to do it were a bit more primitive and you actually needed to know what you were doing a little bit. Firesheep makes it a point and click operation.
Firesheep is a Firefox extension that examines open wireless networks for authentication cookies, and then displays a list of users and Web sites that it's captured. If the Firesheep user snags someone's credentials, all it takes is a double-click to log into the site as the victim. Note that this only works for sites that Firesheep supports — so if you're logging into Twitter, Facebook, etc., then you should worry. You might be safer (from Firesheep, anyway) when logging into lesser trafficked sites. But why chance it?
None of this is entirely new. You could do the same thing with Wireshark (formerly Ethereal), but it takes a wee bit more smarts to piece together the bits with Wireshark.
Want to try Firesheep out on your Linux box to see what it does? Unfortunately, or perhaps fortunately, you can't. Not right now, anyway — it only runs on Mac OS X and Windows, even though it's a Firefox extension. You can grab it from GitHub. There's also a port for, of all things, WebOS.
Fighting Firesheep
If you're convinced that Firesheep and its ilk are a problem, what's the solution? It's a two-parter, unfortunately — and only some of it rests on the users.
What you can do as a user is to force HTTPS connections on sites that support them, and avoid using authentication over public networks if the sites in question do not support secure connections. For instance, if the company Content Management System (CMS) or Webmail doesn't have a SSL cert, wait until you're able to connect over a private network.
Another thing, for Firefox users, is HTTPS Everywhere, which is being developed by the Tor Project and Electronic Frontier Foundation (EFF). Like Firesheep, HTTPS Everywhere doesn't support every Web site — but it does support a wide range of popular sites, including Github, Dropbox, Bit.ly, Twitter, Hotmail, and Facebook. Note that Facebook requires a few additional steps, see the instructions with the 0.9.0 release. In particular, you'll also want the AdBlock Plus extension for Facebook, because a lot of the ads come from insecure sites that have Facebook trackers. (Thanks, Facebook...)
Chrome and Chromium users can use the --force-https option to force HTTPS connections, though this has some drawbacks in that you can't connect to non-HTTPS sites. If you're doing your normal browsing plus connecting to sites using authentication, it can be a pain. Chrome also denies self-signed certificates when using the --force-https option, so that means you're going to be out of luck if your company or project is using self-signed certificates.
In general, the best things you can do is to be aware of the problem and be conscious of when your information could be exposed.
Supporting Your Users
Admins can help by offering secured connections. If you're running a server with any kind of user authentication, you should be offering your users secured connections. This means having an SSL certificate installed and, preferably, only allowing HTTPS connections when authentication is involved.
Computationally, this is a bit more expensive — but you shouldn't need to upgrade your hardware just to support additional HTTPS connections unless you're supporting a lot of traffic.
The other consideration is an SSL certificate. You can purchase an SSL cert from several different companies. Many domain registrars provide SSL certs for a fee, some also provide certs for free with domain registration. Some projects, like StartCOM also provide certs for free. Be careful with some of these — if the root certificate for the SSL provider is not distributed with the browser, the browser will treat the certificate like a self-signed certificate. In other words, the connection may be secure from Firesheep — but it's not verifying that you're connecting to the site you think you're connecting to.
Self-signed certificates are fine for organizations that want to encrypt traffic for a handful of users, and also good if you want to secure your own personal site. For example, I'd much rather have a self-signed cert for my blog when I'm updating it from a conference than to connect in the clear. We'll cover creating self-signed certificates soon.
Summary
Firesheep is just the latest threat to users, but it only exposes a vulnerability that's been there all along. Though there's been a lot of fingers pointed at the Firesheep developer for unleashing this, I think it's a good thing that it's out there. It shows just how vulnerable users have been and, I hope, will prompt users and IT departments, to take these threats more seriously. Linux users are used to scoffing at the malware that continually causes problems for Windows users — but this is a cross-platform problem. Make sure you're taking steps to be safe.
