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.
Did I mention I sell SSL certificates?
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.
Well geepers Mr. Taco how about https on slashdot?
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.
That gives the people who use Firesheep a kind of victory by intimidation. Much better to thwart them than to shy away from social networks in fear.
Guess you're going to have to quit /. because we're using vanilla http at the moment as well.
that SSL was found to be compromised several months back (At least in the case of 128-bit AES). Or is that no longer the case?
We're through being cool! Eliminate the ninnies and the twits! -Devo
Who said anything about using unencrypted sites? The only social networking I use is Facebook, and (as of today, at least) they've got an encrypted version.
That only works if all your friends also decide to do the same.
Use a separate computer or a VM for your "social networking" so your important data is in no danger.
Even a cheap laptop can run vmware player and a small vm with just a browser in it.
Well heck, let's just get rid of the Internet altogether. Just unplug from the Net, and you don't have to worry about spam, malware, or any of the other annoyances and dangers of having your computer connected to the world. People lived and worked before there was an Internet, after all. Olden days of 1995? Why not the olden days of 1985? Or 1905?
Your suggestion, while factually accurate, is more or less impractical in the real world. Social networking is here to stay.
-=+>txtracer<+=-
-Those who do not learn from history are doomed.
So uhm, windows and mac only?
I thought we were supposed to be the sniffing ones!
Unmentioned is the other obvious and simple solution: don't join onto "social networks."
Which may help against the current targetting of certain exploits, but doesn't deal with the main problem. Anything you log into via an unencrypted connection on an unsecured WiFi connection is subject to the same type of attack. (And, anything you log onto via an unencrypted connection over the public internet, even over a wired connection, exposes you to credential stealing by third parties, though only ones with access to the systems over which the information actually travels.)
"Social networks" just happen to be one common class of sites that people log into that often use unencrypted transfer of credentials.
By default, it doesn't force encryption upon logging in. Even if you go there, it reverts to non SSL on every request.
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.
Not necessarily true, Google have a solution which means that
At least anyone wanting to get between you and the cell tower has to use non-consumer hardware. Also AFAIK the 3G security is still holding up reasonably well. 2G is pretty hackable nowadays, but even there the hacker needs something more than just a $200 netbook.
So cellular traffic is more safe, provided that you trust your operator.
It's been best practice for years to use SSL for anything that requires any form of authentication, and plain HTTP for anything which is completely open and anonymous.
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.
big sites should start by redirecting all non-ssl traffic to https automatically.
Haven't you ever heard of SSLProxy or or SSLStrip?
With SSLProxy, the SSL connection is not secure.
With SSLStrip, the server may think the connection is SSL, but the client may not.
As long as the 'redirect to HTTPS' is transmitted over plain HTTP, that redirect can be intercepted and mangled.
simply not using social networks?
*gasp* HERETIC!!!
Who dreams of fire sheep?
I dont. I'll use any Open AP.
I simply connect, fire up my SSL tunnel to home and surf away. or VPN to home, etc... Why dont you do the same? It's trivial to set up and protected you from a lot of things by default.
Do not look at laser with remaining good eye.
It is that it makes pages load slower because browsers do not cache SSL content unless the Cache-Control HTTP header is set to Public. When some of the content in a SSL page, like images, have that header set to Public the browser will show a warning stating that some of the content on that page is not secure frightening the user. So what will a site owner do? 1) Use SSL without browser caching and make the site much slower; 2) Use SSL setting some content as cacheable and risking loosing its users or; 3) Send everything in the open making the ignorant user happier?
2011. The year Gnome decided Linux will never be on the desktop.
and their privacy to be invaded.
So someone can read my profile and find out that I'am a 12yo girl, who really, really likes Ponies??
Or if you have Linux web hosting, just use SSH tunneling . You're already paying for web hosting, might as well get more out of it.
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.
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..
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.
You're absolutely right. I sit corrected. :( Bummer.
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.
Linux web hosting doesn't necessarily mean that you have a shell account, especially on a large-scale shared hosting provider such as Go Daddy.
I know that Gmail can have a whole session over SSL, but what happens if I use another Google property, e.g., Maps, while logged into a secure Gmail session? Would Maps, Voice, etc. not pull out the cookie (created by Gmail) from my browser over HTTP, and would Firesheep not be able to sniff that transfer? Maybe the attacker could even open a non-secure Gmail session of his own over HTTP and read my email too...
Don't use dumbed down providers like HostGator or the atrocious GoDaddy. Dreamhost (for all its occasional problems) provides full shell access with every account (no ridiculous photo ID faxing) with a laid-back attitude as long as you're not bringing down the server. (Doesn't mean they want to ssh tunnel, but they also provide a VPN option.)
There are also some venerable free providers out there, but the rule is to not talk about them.
I'm not a lawyer, but I play one on the Internet. Blog
The greatest way to have safe sex is not have sex at all.....makes a lot of sense right? How about we stray away from focusing on not using free wifi and more of the problem of secure webpages.
I don't worry about it a bit. But then, I don't use Facebook or bank or pay bills over the internet, and I run Linux with a strong root password. I'm not invincible, of course, but I'm pretty safe.
Free Martian Whores!
But since you are a sensible, prudent person you wouldn't be using Gmail for anything really sensitive anyway without encrypting it...
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.
The right answer is to use encryption on all websites. Unfortunately we're not yet at a point where all websites can be bothered to support encryption which means that we should use encryption for every website that supports it and carefully consider whether websites that don't support it are worth the risk. It would be nice if your web-browser would automatically use encryption on sites where it is available and, thanks to the EFF, there is a Firefox plug-in that does just that. Consider giving HTTPS Everywhere a try.
yes indeed. I've been tunneling all my outbound traffic over a localhost SSH SOCKS proxy for years precisely because I don't want anybody else on the LAN (wireless or otherwise) to be able to sniff that traffic. my ISP sniffing, well, I'm stuck with that for non-HTTPS traffic - but I can prevent the rest. To wit: http://cleverhacks.tumblr.com/post/443759182/ssh-its-whats-for-dinner-or-socks-proxy-port and if you can't get out on anything but tcp/443, see also: http://cleverhacks.tumblr.com/post/816507010/ssh-over-ssl-tunneling
illum oportet crescere me autem minui
Personally I love the idea of firesheep (although it's not new...just user-friendly). That said, I can't wait for e-mail sheep, instant message sheep, sms sheep etc.pp.. I'd like to see Terrabytes of peoples conversations using any of those ways posted publicly. Ditto for voice (phone) conversations. Post it, post it and post it again. Until even the last grandma understands the realities of electronic communication and *wants* to encrypt.
People lock their doors because they perceive of getting a benefit from it (lock door = kids & stuff inside are safer). All we need is for them to extend the same mindset to online interactions with people. For that to happen, they need to perceive a *real* threat that they can look at themselves "Mom? I just found a hot chat you did while away for your business trip on Google. Dad is PISSED and who's David anyway?!"
Imagine, if people saw their last 300 e-mails posted on Usenet....
I don't ever want to see anything again, why Johnny can't encrypt. I want Johnny to slap me in the face if I even suggest he contact me without encrypting!
1% at Google is still 1% at Joe's Discount Server Shack.
You do understand how percentages work, right?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
ipad, touch, new air only has an Apple USB ethernet adapter as an extra. The world in some tech areas is going wifi and news like this is not good with todays low low encryption 'options'.
Someone is going to have a lot of fun collecting all this data.
Domestic spying is now "Benign Information Gathering"
IMO, SSL should go away.
Instead of SSL, new encryption for the web would appear using DNSSEC.
Certificates would be stored in DNS. The same certification and signature that certifies that "www.blah.com" matches to "1.2.3.4" would certify that is the correct public key for www.blah.com.
Storing certificates in DNS prevents a rogue CA issuing a certificate for a site.
And it prevents say NSA etc getting fake certificates made up (no evidence exists to suggest this has happened but lots of suggestion that it could)
It also prevents a certain kind of man-in-the-middle attack used by some firewall products that basically install their own root CA on all the client PCs and use that to carry out MITM attacks (either to block banned websites or to monitor communications for theft of confidential information)
And yes, I did see such a firewall product in the past (cant find a cite for it now)
https://facebook.com/ works just fine.
https://slashdot.org/ doesn't, it redirects to http:///
But I agree, SSL should've become the default long ago. Has someone already made a Firefox plugin that for every http:/// link tries the https:/// equivalent first and then falls back to http:/// only if that fails?
Assorted stuff I do sometimes: Lemuria.org
Talk to people? Like... in real life?
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
DNSSEC lets us get rid of CAs, at least for low-importance certificates.
As I understand it, this works by putting a self-signed certificate in a CERT record and validating it with DNSSEC. But an update to existing devices to support DNSSEC and CERT records is no more likely than an update to support SNI.
Any device that still has that issue is broken.
When the majority of your customers' devices are broken, it is far more profitable to work around brokenness rather than turning away your customers.
Then, on the http site, explain that for better privacy they can switch to https. Make simple and explain what the warning screens will mean.
Make simple and explain what the warning screens will mean.
Untrusted issuer could mean you're about to get MITM'd. It has happened. To guard against this, the operator of the web site will need to offer the fingerprint elsewhere for comparison. Is there a best practice, other than just paying for a commercial CA certificate? And if you're on shared hosting, how does the server know which domain's certificate to present before the browser (which more likely than not runs on a platform lacking SNI) sends the Host: header?