Slashdot Mirror
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.
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.
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
How about you RTFA? It's obviously not specific to social networks.
Guess you're going to have to quit /. because we're using vanilla http at the moment as well.
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").
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.
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.
What a fool believes, he sees, no wise man has the power to reason away.
Not necessarily true, Google have a solution which means that
Put SSL accelerator appliances in front of the webservers, use dedicated hardware which is designed to handle ssl.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Now, firesheep is ooh scary because it makes it visible and obvious that complete strangers can jack-yo'-myspace in the coffee shop.
This works because an open WLAN is the equivalent of an old unswitched ethernet network, with every wi-fi reciever in radio range plugged in. It can be mitigated, however, if you are VPN connected to a secure network, because your traffic will be nothing but inscrutable VPN noise, even if the site in question is sloppy.
However, here is the part where the paranoia starts to tickle... Y'know who always has access to any traffic that isn't encrypted between you and your remote host? Your ISP. Y'know who(unless you are buying a pretty serious business class line) you've signed a ridiculously one-side contract with, one that allows them to do basically anything at any time, for any reason? Your ISP. Y'know who hates being reduced to a dumb pipe, and looks covetously at the ad money flowing through the various web companies? Your ISP(See Phorm, Nebuad, et al.). Y'know who could be, totally silently, Firesheeping every non-SSL login you make, and observing all the fun consumer data that advertisers will pay for? Your ISP...
Forget the neckbearded script-kiddie in the coffee shop. He is trivial to work around.
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.
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.
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.
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.
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 -- 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.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
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.
Use a switched network ....
This is a packet sniffer. If you are on a switched network, the degree of difficulty to pull this off is much greater. it is not a solution because of other tricks like arp poisoning.
This is nothing new, but it is good publicity to remind people how important SSL is. This addon did not change anything except now more script kiddies have access to another tool.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
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.
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Less than 2%. Before you ask, the RAM overhead was under 10 KB/connection.
Seriously, the old "but SSL overloads the servers" crap is completley out of date. It costs a *tiny* bit more, yes, but the end result is far better.
Source: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
There's no place I could be, since I've found Serenity...
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.