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

Defense is Easy

[The_mad_linguist]

All you really need to do is stay out of the tall grass on Route 32. If you do have a firesheep attack, I recommend sending out a water type like wartortle.

Re:Defense is Easy

[Monkeedude1212]

Come on, we're all adults here.

Meaning, you should have a Blastoise by now.

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:slashdot's method

[NatasRevol]

I *did* make the same post!

Re:how about

[rakuen]

Guess you're going to have to quit /. because we're using vanilla http at the moment as well.

Myopic view of how browsers treat SSL

[kamelkev]

The idea that "It seems to me that the big sites should start by redirecting all non-ssl traffic to https automatically" is very shortsighted when you consider how social networking sites actually work.

Social networks by their very nature include cross posting of content found from around the internet. If a site is running in "SSL only" mode then you'd very quickly see intermixed SSL and non-SSL content living side by side, and this creates a disaster for the admins of any web service.

For those who aren't familiar, modern web browsers throw up warnings whenever you intermix SSL and non-SSL content - it's been this way for years, it's a problem for anyone who accepts user generated content cross-site content.

If someone like Facebook were to implement this policy they'd immediately get a flood of complaints about these warnings.

SSL isn't very good protection nowdays anyway - we need something better.

Re:Let's just encrypt everything all the time

[bunratty]

I read that when Google switched Gmail over to HTTPS that their server load increased by 1%. Today's CPUs are blazingly fast. Why would you think that the server load would be an issue with encryption and decrypting all communication? A web site is largely about having a large enough Internet connection and a large and fast enough database to keep up with the Internet traffic. Those CPUs are mostly just sitting around twiddling their thumbs waiting for I/O.

Re:That's Expensive

[IAmGarethAdams]

Not necessarily true, Google have a solution which means that

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

Re:Let's just encrypt everything all the time

[RedACE7500]

Just terminate the SSL at your load balancer. This also allows you to offload the SSL work to a machine(s) dedicated to do so and keep that work off your web servers.

Re:That's Expensive

[gad_zuki!]

The difference here is that gmail and facebook are two very different applications. Facebook relies on a lot of client-side caching (html pages, photos, graphics, flash objects, etc) while gmail is mostly dynamic and does a lot of heavy lifting on the client side. With SSL enabled the clients won't cache anything and mixing http and https objects throws a security error on one or more of the major browsers. I'm sure Facebook can force SSL but end users won't like the diminished performance and if Facebook mixes items then end users will complain or freak out when their browser warns them about it.

I think the browser makers need to address this. I don't see why we shouldn't cache SSL items. They can simply be cached in an encrypted volume using the SSL key. That's probably less of a performance hit than going back on the network and re-requesting all those objects.

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.

Re:That's Expensive

[goofy183]

You can tell a browser to cache things provided over SSL by setting the cache-control and expires headers appropriately as well as making use of etags and 304 responses. Its not hard and with good use of etags you can reduce a LOT of both network and application work.

Re:Let's just encrypt everything all the time

[dgatwood]

Akamai works just fine with SSL. Akamai is not a transparent cache, but rather an explicit push cache in which a web administrator chooses content to host on Akamai, pushes the content to their servers, and modifies local content to point to the Akamai copy when it has been fully staged. Akamai has supported SSL for almost a decade now.