Blog   |   Internet

Protecting journalists from Firesheep

Wifi users at a McDonald's in Manhattan. (AP/Bebeto Matthews)

There's been a great deal of coverage in the last day or so of Firesheep, a plugin for Firefox that lets you take over the Facebook and Twitter accounts of others on your local network. If you use Firesheep, you can pick one of the people on, say, the same open wireless at your nearby cafe, and then easily view, delete, and add comments using their name on these sites.

Firesheep exploits the fact that those working in the same office or using the same wireless network can monitor all the unencrypted Internet traffic on your shared network. If you can intercept this traffic, you can lift from it the browser cookies that identify a user to a site like Twitter or Facebook after they log in. Using these cookies yourself allow you to mimic that user. Firesheep automates the steps needed to perform this mimicry.

The security flaw that Firesheep uses has been known for a long time. It's not so much a specific bug as a presumption by the makers of these websites. These and many other Internet services assume that you can trust every machine that might be able to monitor your communications. Because of the design of the Net, that includes any computer between you and the site you visit, and anyone sharing the same local network as you.

As Firesheep illustrates, that degree of trust may be a poor assumption when you're sitting in a café full of strangers. But for many journalists working in authoritarian regimes, trusting potential listeners is a poor assumption at any time, even when you're using a private Internet connection or a mobile phone. The phone company or Internet service provider you use may have close links to parties with an interest in monitoring or masquerading as you. They may well have far more sophisticated tools than Firesheep in their repertoire.

Permanently protecting against Firesheep and similar attacks means breaking this trust of machines between you and the sites you intend to communicate with. Stopgap advice such as "do not use open wifi networks" do not fix this underlying problem. While Firesheep does not automate the entire process of hijacking traffic on these "secured" networks, the possible attacks are well known and will be made simple to use in the near future.

One concrete way large sites could improve security for their users would be to provide and publicize an encrypted "https" version of their site. End-to-end encryption like https ensures that no one except the site you're talking to can monitor or imitate your Internet traffic. It stops casual intercepters like your local Firesheep user; and it also stops the more determined adversaries that journalists might face. Both Twitter and Facebook already offer this feature, although their support is sometimes patchy. CPJ offers an https version of our site, and we encourage others to do the same. Use the https-everywhere plugin to guarantee you'll always use the https service where available.

Another way that journalists can protect themselves is to use a virtual private network (VPN). VPNs encrypt and then transfer all of your Internet traffic to another remote network, which then connects to the site you intend to visit. The final connection may be unencrypted and therefore vulnerable, but it may be better placed, away from potential eavesdroppers. Depending on whether your employer provides it or you buy such a service yourself, the remote network might be your office workplace, or a machine in a country like Sweden or the United States where there may be a lower risk of interception by interested parties.

Firesheep's author has publicized security flaws that have been long known, and largely ignored by large Internet companies. Journalists in dangerous conditions are particularly vulnerable to these attacks. We can hope that the storm of publicity over this compelling public demonstration will lead to the flaws being fixed for everyone, on every site.

Like this article? Support our work

Comments

HTTPS-Everywhere just sets up HTTPS for major sites. You can also add sites to the configuration via their website instructions.

You say that you provide HTTPS, which you you... except that my browser raises a warning - "This page includes other resources which are not secure". So even an article about the insecurity of unencrypted communications still uses unencrypted communications to the some domain (cpj.org) causing any appropriate user cookies to still be sent in the clear.

Peter -

Well, that depends on the site. You can set individual cookies to only be sent only over encrypted channels, and not all sites encode valuable info in unsecured cookies (cpj.org doesn't use reader cookies for authentication, AFAICS).

But your general point is spot on -- you only get all the benefits of a secure connection if you encrypt everything, and that can be tricky. It's one of the reasons why https-everywhere and other plugins like Force-TLS are currently needed, to enforce https connections even when the Web page asks for an http version.

And one final note: the post at http://codebutler.com/firesheep-a-day-later by the authors of Firesheep does a great job at explaining in more depth what it does, what the real problems it exposes are, and how to fix them.