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.
Re:how about (Score:3, Informative)
How about you RTFA? It's obviously not specific to social networks.
Re:how about (Score:3, Informative)
Re:how about (Score:1, Informative)
By default, it doesn't force encryption upon logging in. Even if you go there, it reverts to non SSL on every request.
Myopic view of how browsers treat SSL (Score:4, Informative)
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 (Score:5, Informative)
A little paranoia here... (Score:3, Informative)
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.
Re:Let's just encrypt everything all the time (Score:3, Informative)
Virtual Domains don't work with SSL (Score:1, Informative)
Yeah, let's just encrypt everything all the time, except for very small sites that do not use any authentication.
The biggest issue that I see with this is that you for most situations you cannot do virtual domain hosting with SSL. For those who aren't familiar it works like this:
www.example1.com, www.example2.com and www.example3.com all point to one ip address (let's say its 192.168.42.42). When a request is made to port 80, the webserver looks at the domain specified in the request to determine which of the three sites to return data for.
With SSL, the encryption has to be established BEFORE the request is sent, so the web server can't change SSL certificates based on domain. The only way you could make it work is if the SSL certificate was issued for ALL of those domains; a situtation that won't work if you aren't the only one using the hosting service..
Re:That's Expensive (Score:4, Informative)
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 (Score:4, Informative)
Akamai works just fine [revealingerrors.com] 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.
Re:Let's just encrypt everything all the time (Score:3, Informative)
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 [imperialviolet.org]