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.
Defense is Easy (Score:5, Funny)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
Blastoise, I choose you!
Blastoise uses "SSL Fountain"!
It's super effective!
Re:Defense is Easy (Score:5, Funny)
Come on, we're all adults here.
Meaning, you should have a Blastoise by now.
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: (Score:2)
What's "private" about anything on Slashdot?
Re: (Score:3, Funny)
My precious, precious karma. :)
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
The question was about privacy, not impersonation.
Re: (Score:2)
Re: (Score:2)
"Well, Ms. Bunratty, I see you posted a GNAA troll on slashdot. Sorry, we can't hire you."
"My name's Smith, how did you know my slashdot user name?"
Re: (Score:2)
I would prefer that my ISP, employer, etc. does not know what I post to slashdot.
Re: (Score:2)
Then I suggest that you not post it, since Slashdot is open to the public.
Re: (Score:2)
Not all of us are dumb enough to use our real names, Mr. Hasler.
Re: (Score:2)
Your real na... oh. Well, you and I and a few others are the exceptions here.
Re: (Score:2)
I was just about to make the same post.
Re:slashdot's method (Score:4, Funny)
I *did* make the same post!
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
In all seriousness, people should not be using Facebook in a way that could cause any damage to them if their accounts are hijacked. Facebook is a toy, and treating it like anything other than a toy is asking for trouble.
Re: (Score:2)
Did you actually think about what you said before you posted? How the hell does how somebody use Facebook in a way that there's no risk of serious damage? If I hijack your account, I can change all your privacy settings, upload all the pictures I want (they might not be your pictures, but that doesn't mena you want them on your profile), post comments, join groups, send nasty break-up letters to your girlfriend, and declare your undying love of the church of scientology in exchange for all the horrible prob
Re: (Score:2)
How the hell does how somebody use Facebook in a way that there's no risk of serious damage?
By not choosing it as your primary communications tool? If your girlfriend thinks you are breaking up with her because of a message you sent on Facebook, then something is wrong. Seriously, I could just as easily register a Facebook account in your name, then send friend requests to all the people I want to have see your undying love for Scientology.
The real problem is that people are taking Facebook seriously. If you receive an important-looking or surprising message on Facebook, you should request
Re: (Score:2)
using Facebook as anything other than a toy is a really stupid thing to do.
One could say that for the whole Internet. Sadly, other people searching for your name to see what you've posted and what groups you've joined and what the timestamps are on your messages (were you posting during working hours?) may or may not comprehend that the presence of your name is not your fingerprint. Somebody was using a quote of mine from the RISKS newsletter, with my name as attribution, as their sig for a while; my name was in a LOT of places where I didn't put it. And that wasn't intended as
Re: (Score:2)
Re: (Score:2)
There's nothing on Slashdot that really merits privacy. Something like Facebook, where people basically post intimate details of their lives, is a very different thing.
From NSFW: [slashdot.org]
Re: (Score:2)
slashdot's method (Score:2)
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??
Re: (Score:2)
Yeah -- I just tried https://slashdot.org/ [slashdot.org] and got redirected to http://.../ [...]
Not cool.
Linux version? (Score:2)
So uhm, windows and mac only?
I thought we were supposed to be the sniffing ones!
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: (Score:2)
Re: (Score:2)
Whenever an HTTP element (of any kind) on an HTTPS page is loaded, a big hairy warning message pops up.
Re: (Score:2)
Re: (Score:2)
Had to be for what? In order to display at all? In order to get the error message?
I believe the rule is just what I said.
Re: (Score:2)
It doesn't matter what domain the HTTP content is coming from. ANY HTTP content from ANY domain on an HTTPS page results in a warning.
Re: (Score:2)
Re: (Score:2)
Facebook already has this as far as I can tell. There's a firefox addon that forces https whenever the site has it. It works for facebook. It just ends up disabling the chat function.
Obvious... (Score:2)
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.
Re: (Score:2)
It's best practice to always use SSL whenever possible, period. After all, if the connection isn't encrypted, the user's ISP might listen in, and with all countries nowadays trying to implement their own version of Eye of Sauron, any small bit of obfuscation helps.
And https is simply HTTP sent over SSL-encrypted connection.
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: (Score:2)
Re: (Score:2)
StartCom offers free x.509 certificates, and their root is trusted by Windows/IE, Mozilla, and Mac OS / Safari.
Re: (Score:2)
StartCom offers free x.509 certificates
But you still need an IPv4 address to use a certificate until SNI-incapable clients disappear in three and a half more years [microsoft.com]. Once ARIN runs out of blocks to hand out to regional registries, which in turn run out of blocks to hand out to hosting providers' ISPs, watch hosting providers charge plenty extra for a hosting tier that supports SSL.
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: (Score:3, Insightful)
So what?
Re: (Score:2)
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.
Even with a split tunnel? And who would not be using a split tunnel these days?
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.
If androids dream of electric sheep... (Score:2)
Re: (Score:2)
Fire nation soldiers of course.
Use a switched network (Score:3, Interesting)
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.
Re: (Score:2)
arp poisoning doesn't work on wifi APs since they know the difference between LAN and WAN... and many of them don't allow LAN-to-LAN communication at all.
I want more... (Score:2)
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 fr
Where are the wires? (Score:2)
Someone is going to have a lot of fun collecting all this data.
SSL should go away (Score:2)
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 cou
Re: (Score:3, Informative)
How about you RTFA? It's obviously not specific to social networks.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Not a great answer (Score:2)
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.
Re: (Score:2)
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 hap
Re: (Score:2)
Re: (Score:2)
Mathematically, no big deal; but in practice, potentially an issue.
Re: (Score:2)
https://www.eff.org/observatory [eff.org] has more details on the ~650 different entities who will be silently trusted by your standard IE or FF install.
Re: (Score:2)
> > SSL has, potentially, been seriously compromised in that some fairly dodgey entities are trusted issuers
> > from the perspective of the vast majority of consumer browsers, etc.
> Now that I'm curious, who are the dodgey entities?
Edit / Preferences / Advanced / Encryption / View Certificates / Authorities
Your welcome!
Re: (Score:2)
> SSL has not been compromised.
We agree!
Your NSA :-)
Re: (Score:2)
There's a couple of Firefox extensions that actually do encrypt everything all the time ... or, at least, they redirect everything that has an encrypted SSL to that HTTPS URL instead.
HTTPS Everywhere | Electronic Frontier Foundation [eff.org]
(which is also here: HTTPS Everywhere :: Add-ons for Firefox [mozilla.org])
Force-TLS :: Add-ons for Firefox [mozilla.org]
Re: (Score:2)
I use satellite for my internet access, encrypted connections are horribly slow on it.
Re: (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: (Score:2)
Correct. SSL taxes the front-end web server cluster a bit more, and worse is that you can't do any sort of anycast global load balancing because of the SSL session state.
Re: (Score:3, Informative)
Re: (Score:2)
This works as long as your load balancer supports it. HA Proxy, for example (which is used by A LOT of folks), doesn't support it. From their site:
People often ask for SSL and Keep-Alive support. Both features will complicate the code and render it fragile for several releases. By the way, both features have a negative impact on performance :
Having SSL in the load balancer itself means that it becomes the bottleneck. When the load balancer's CPU is saturated, the overall response times will increase and the only solution will be to multiply the load balancer with another load balancer in front of them. the only scalable solution is to have an SSL/Cache layer between the clients and the load balancer. Anyway for small sites it still makes sense to embed SSL, and it's currently being studied. There has been some work on the CyaSSL library to ease integration with HAProxy, as it appears to be the only one out there to let you manage your memory yourself.
Re: (Score:2)
Forget to add in my previous post: If you're doing global anycast, there is no effective way to share SSL session state between two geographically distant load balancers (at least, not that I'm aware of).
Re: (Score:2)
People roaming around (eg on the campus WiFi) wouldn't pose a problem because that's all behind a NAT, so your external IP+port stays the same even if your local IP changes. This wouldn't solve the problem of eavesdropping--people could still see my Facebook session--but at least they couldn't jump in and start posting on my wall.
Aren't you contradicting yourself here a bit? Wouldn't the same NAT feature that would allow you to roam around campus allow others on campus to hijack your session? (Or am I misunderstanding something?)
Re:Let's just encrypt everything all the time (Score:5, Informative)
Re: (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
Re: (Score:2)
You can just set the cookie to be sent only on an SSL session and not bother using a different domain. Then put all the stuff that doesn't require authentication (and hence can be cached in the first place) on http links.
Of course idiot browsers stop you from doing this in practice because the popup a scary alert about insecure content on a secure page and default to not showing it.
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: (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]
Re: (Score:2)
I suspect that it's also an issue of Google having a nigh-infinite number of servers and very good load-balancing. ;-)
Re: (Score:2)
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: (Score:3, Interesting)
Put SSL accelerator appliances in front of the webservers, use dedicated hardware which is designed to handle ssl.
Re: (Score:2)
By definition, if you don't care about privacy you don't understand the issue.
Re: (Score:2, Offtopic)
You can get a wildcard certificate relatively cheaply which would be valid for any subdomain of slashdot.org, StartSSL charge $50 for 2 years for instance (and they offer normal non wildcard certs for free).
Re:That's Expensive (Score:4, Interesting)
Not necessarily true, Google have a solution [imperialviolet.org] which means that
Re:That's Expensive (Score:4, Interesting)
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.
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: (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
Re: (Score:2)
1% at Google is still 1% at Joe's Discount Server Shack.
You do understand how percentages work, right?
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Shell providers (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
But since you are a sensible, prudent person you wouldn't be using Gmail for anything really sensitive anyway without encrypting it...
Re: (Score:2)
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 [tumblr.com] and if you can't get out on anything but tcp/443, see also: http://cleverhacks.tumblr.com/post/816507010/ss [tumblr.com]