How To Protect Against Firesheep Attacks

Monday we mentioned Firesheep, a plug-in that trivializes ID spoofing on social networks. Since then various security researches have come out to suggest How to Protect Yourself against Firesheep Attacks (submitted by Batblue). Of course the advice is pretty obvious: Don't use free Wi-Fi, use SSL, or a VPN. It seems to me that the big sites should start by redirecting all non-SSL traffic to https automatically. If you want to be insecure, you'd have to explicitly state that you can't encrypt for some reason.

Comments

slashdot's method

[Lord Ender]

Slashdot does the opposite. It redirects SSL connections to HTTP. They must want their users' accounts to be hijacked... and their privacy to be invaded.

Re:A little paranoia here...

[fuzzyfuzzyfungus]

Given that transmissions from both the AP and the client are in the clear, and generally coming from a reasonably omnidirectional antenna, AP isolation on an open AP doesn't buy you very much.

It does slightly inconvenience the attacker(since they need a NIC that will let them listen in promiscuous mode, and probably something closer to Wireshark than Firesheep, for all frames being transmitted about, rather than just connecting to the network and getting them for free, unswitched network style); but all the data are still flying around in the clear, subnet isolation or not.

Re:Let's just encrypt everything all the time

[vadim_t]

last, maybe you have the budget to be running as many servers and to be hogging as much energy as you want, but what about all the mobile phone users connected to your site? is it acceptable that every single little AJAX interaction now has to go through the encryption/decryption straw on their 400 mhz oldschool mobile phone?

Sure, why not? I tested mine, it can do aes-128 at 8MB/s. That may not seem like terribly fast, but it's faster than the ideal case for 3G (with the real world rate being considerably lower)

My laptop (nothing especially impressive, chosen for battery time and not power) can do it at 90MB/s. My desktop does it at 250MB/s, and isn't terribly new either (Phenom II 940).

what about places where, for various reasons, encryption is controlled or restricted? are we going to tell them no, unless you have full end to end encryption, you cant use the web?

Yes? Because those places either have no access to anything modern anyway, or nobody cares about what the law says. Encryption is so common that many games like WoW use it.

the hubris of "just throw more end to end encryption" at it is bullshit, rotten wrong incorrect bullshit. what we need is a cookie solution not susceptible to man in the middle attacks. anything else is irresponsible overkill, and ignorant to the real problem and diverse requirements and use cases of the web. authentication does not have to be tied to end to end encryption, at least thats my mangled crippled understanding of Kerberos.

Why? You provide no good justification for it. The fact is that currently encryption is fast even on limited devices on cell phones, and on modern hardware doing full disk encryption amounts to a rounding error. Encryption is also easy to implement in hardware, where it gets even better performance.

I don't understand why would it be "hubris" anyway. The way I see it, everything remotely possible should be encrypted, all the time. There's no good reason for random third parties to be looking at my packets anyway.