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?
simply not using social networks?
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?
I have a lot of anxiety using free hot spots in stores and coffee shops. I got a Driod X recently and I am tethering from it via USB rather than the wireless mode. I feel a lot safer, but - is the cellular traffic from the phone to a cell tower relatively secure?
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.
Encryption is fast, but if you do it for every page view the cost to providers will add up.
Unmentioned is the other obvious and simple solution: don't join onto "social networks." I'm sure there'll be fifty replies explaining how they just have to be a member of the same useless cow-tipping, todays-sandwich-blogging, incessant-nagging network that their great Aunt Muriel is on, but you can in fact live a reasonably active and social life like they did in the olden days of 1995. No spoofing concerns either.
[
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
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.
So uhm, windows and mac only?
I thought we were supposed to be the sniffing ones!
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.
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.
...do it now! Do it!
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.
Delete your social networking profile and talk to people instead. I am 28 and happy I left Facebook.
Who dreams of fire sheep?
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.
Sorry to post this here -- this morning I finally got around to searching the /. faq, looking for the reason why, in recent days, I cannot change thresholds in the classic discussion system (as I have for 12 years) when not logged in & running noScript. There's nothing about changes in the faq. Is this a maneuver on the part of /., i.e. taking away basic functionality, to try to get me to log in? I can't always be logged in -- there's a thing called a "boss" that wouldn't like that too much. Can anyone shed light on this?
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??
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..
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 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.
<?php
# SSL Local Redirect
# ******************
$ssl_enabled = TRUE;
if($ssl_enabled) {
$re = $_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"];
header("Location: https://$re");
}
?>
Why would anyone expect a company to be responsible to a person, the public, a nation, a species?
"Big sites should start by redirecting all non-ssl traffic to https automatically" you ask to much of an institution/company, consideration of right and wrong is a human idiosyncrasy.
As if a company could ever feel guilt of remorse about trivialities. Chemical spills in India and other places (EU, US, RO, CN...) have caused mass murders, but there is seldom a trial and the penalty for the company C*O is usually less than a slap on the hand, followed by a pat on the back and a larger annual bonus.
Expecting business and institution responsibility to a person or the public is species-hubris and silly.
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
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.
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.
Why would advice purporting to recommend good Internet security habits suggest that people not use SSL or a VPN?
OH WAIT I FORGOT THIS SITE IS RUN BY ILLITERATE CODE MONKEYS!
I kid, I kid. 3
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!
What can be done to protect mobile devices, such as smart phones, from such attacks?
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)
Posting anon as I'm not sure if I know what I'm talking about. Please be gentle with flamthrowers...
[/disclaimer]
If I've understood correctly what the firesheep is taking advantage of and what NoScript HTTPS FAQ states, then NoScript will offer protection against this vulnerability.
Quote from the FAQ http://noscript.net/faq#qa6_4
Q: What can NoScript do against HTTPS cookie hijacking?
A: HTTPS cookie hijacking happens when a site sets sensitive cookies (e.g. those identifying authenticated sessions) over HTTPS connections but "forgets" to flag them as "Secure". This means that subsequent unencrypted (non-HTTPS) requests for the same site will leak the session cookies away, even if you logged in securely. NoScript provides means to mitigate this issue, configurable in NoScript Options|Advanced|HTTPS|Cookies. If Enable Automatic Secure Cookies Management is checked, NoScript will try to "patch" insecure cookies set by HTTPS sites on the fly:
1. If the site matches the "Ignore unsafe cookies..." pattern list, NoScript lets its cookies pass through untouched
2. If the site matches the "Force encryption for all the cookies..." pattern list, NoScript appends a ";Secure" flag to every non-secure cookie set by this response
3. Otherwise, NoScript just logs unsafe cookies BUT if no secure cookie is set in a HTTPS transaction setting other (unsafe) cookies, NoScript patches all these cookies with ";Secure" like in #2. However, if a navigation from an encrypted to a non-encrypted part of the same site (i.e. sharing the same cookies) happens in the same tab, NoScript removes its ";Secure" patch to ensure compatibility. When it happens, this event is logged to the Error Console, along with a recommendation to try forcing HTTPS by listing this site in the HTTPS|Behavior|Force section.
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
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?