How To Protect Against Firesheep Attacks 208
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.
slashdot? (Score:1, Insightful)
Well geepers Mr. Taco how about https on slashdot?
slashdot's method (Score:5, Insightful)
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:Let's just encrypt everything all the time (Score:3, Insightful)
I think it is the cost of the extra server load, not the cost of certificates that keeps FaceBook off https. After all, most of their users don't care about privacy (and I mean that they don't care, not that they "don't understand").
Re:A little paranoia here... (Score:4, Insightful)
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:That's Expensive (Score:3, Insightful)
1% of Google's CPU load.... that's 1% of the biggest collection of the largest data centers on the planet. Find a real metric for SSL cost, including any additional latency full end to end induces on each request, or GTFO.
Conversely, people saying "it's expensive" should have some numbers as well. Both on cpu utilization, request latency, effects on http pipelining, &c &c &c. SSL has numerous "costs", including places where full end to end encryption is not permitted. Ultimately the argument that seals the deal is the last one: this is an authentication problem, a trivial MITM attack; that doesnt require end to end encryption, that just requires authentication (see: Kerberos). Cookies, by themselves, just happen to not cut it there.
SSL doubles the cost of a personal web site (Score:3, Insightful)
It's best practice to always use SSL whenever possible, period.
Which doubles the cost of hosting a personal web site. How do you plan to make the business case to hobbyists that an SSL certificate from a commercial CA and a dedicated IPv4 address* are worth the extra $50/yr on top of the $50/yr that they're already paying for a domain and budget shared web hosting?
* Windows XP, BlackBerry, and iOS before 4 don't support the extension that allows name-based virtual hosting over SSL [wikipedia.org].
Re:A little paranoia here... (Score:1, Insightful)
So it's only a problem at places where a complete idiot set up the wireless.
Or setup by a neckbearded script-kiddie in a coffee shop -- just because there's a properly adminned network doesn't mean you're connected to it.
Re:Let's just encrypt everything all the time (Score:3, Insightful)
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.
And what about their bandwidth usage?
There is a well-thought out caching system in HTTP [mnot.net] -- implemented throughout the internet -- that saves a lot of bandwidth. You can kiss all this goodbye, and have every request come to your server. This also means akamai doesn't work, which many large sites rely on.
The real solution for facebook and others would be to make large, static content, such as images, stylesheets available on another, cache-able domain, and not send cookies on this domain. The dynamic content -- and javascript -- should stay on the main domain and be encrypted.
"Let's just encrypt everything all the time" is just a narrow-minded comment of an end-user.
Re:Let's just encrypt everything all the time (Score:4, Insightful)
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).
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.
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:A little paranoia here... (Score:3, Insightful)
So what?
Re:Let's just encrypt everything all the time (Score:2, Insightful)
No, you asshat. We just don't care about certain things remaining private that you care about. You might as well say anyone who goes outside "does not care about privacy."
I don't care if a corporation knows I like Ben Folds and have a friend who goes to MIT. I do care if a random person at Borders can log in as me and change my profile picture to Goatse or send a message to a friend insulting them subtly, so that it is not obvious that I was hacked.