×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How To Protect Against Firesheep Attacks

CmdrTaco posted more than 3 years ago | from the oh-that-helps-sure dept.

Electronic Frontier Foundation 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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

208 comments

Let's just encrypt everything all the time (1, Funny)

Anonymous Coward | more than 3 years ago | (#34039490)

Did I mention I sell SSL certificates?

Re:Let's just encrypt everything all the time (0)

bunratty (545641) | more than 3 years ago | (#34039858)

SSL certificates cost about $10-$15 per year for each subdomain. Unless your site is like Slashdot's with a subdomain for each topic (e.g. apple.shasdot.org, ask.slashdot.org, ..., yro.slashdot.org) the cost for SSL certificates is minimal. Yeah, let's just encrypt everything all the time, except for very small sites that do not use any authentication.

Re:Let's just encrypt everything all the time (2, Insightful)

John Hasler (414242) | more than 3 years ago | (#34039942)

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:Let's just encrypt everything all the time (1)

TooMuchToDo (882796) | more than 3 years ago | (#34040050)

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:Let's just encrypt everything all the time (3, Informative)

RedACE7500 (904963) | more than 3 years ago | (#34040184)

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.

Re:Let's just encrypt everything all the time (1)

TooMuchToDo (882796) | more than 3 years ago | (#34040362)

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:Let's just encrypt everything all the time (1)

TooMuchToDo (882796) | more than 3 years ago | (#34040376)

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:Let's just encrypt everything all the time (0)

Anonymous Coward | more than 3 years ago | (#34040052)

They don't care because they don't understand. Srsly

Re:Let's just encrypt everything all the time (4, Informative)

bunratty (545641) | more than 3 years ago | (#34040056)

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.

Re:Let's just encrypt everything all the time (0, Troll)

LordMyren (15499) | more than 3 years ago | (#34040544)

apologies, but "you're not using your servers" is a dump truck of horse shit. oh so our elastic cloud has free time, eh? electricity is now free? we dont know how to scale, how to utilize?

maybe if someone actually had quantified what kind of utilization end to end SSL required, you'd have half a leg to stando n. but citing google's use in this case means exactly what? you've cited a figure thats not an absolute value, so let me ask, 1% of what? you think their gmail servers are just dumping static text files over the network, that its 1% of almost nothing and thus SSL is free? or is there a chance those servers work their ass off, and they work so hard and do so much that what could be a colossal ssl task is margin error, simply because gmail is atlas, crunching the full text of your and 20GB account realtime with ease? it is impossible to do anything but guess, given your wishy washy proclamation.

last, maybe you have the budget to be running as many servers and to be hogging as much energy as you want, but what about all the mobile phone users connected to your site? is it acceptable that every single little AJAX interaction now has to go through the encryption/decryption straw on their 400 mhz oldschool mobile phone? what about places where, for various reasons, encryption is controlled or restricted? are we going to tell them no, unless you have full end to end encryption, you cant use the web?

the hubris of "just throw more end to end encryption" at it is bullshit, rotten wrong incorrect bullshit. what we need is a cookie solution not susceptible to man in the middle attacks. anything else is irresponsible overkill, and ignorant to the real problem and diverse requirements and use cases of the web. authentication does not have to be tied to end to end encryption, at least thats my mangled crippled understanding of Kerberos.

Re:Let's just encrypt everything all the time (0)

Anonymous Coward | more than 3 years ago | (#34040862)

So for you using VPN must be total lunacy.

Re:Let's just encrypt everything all the time (1)

Stregano (1285764) | more than 3 years ago | (#34040892)

Wait, what are older mobile phone doing on AJAX heavy pages anyway?

Re:Let's just encrypt everything all the time (2, Interesting)

Bert64 (520050) | more than 3 years ago | (#34040142)

Put SSL accelerator appliances in front of the webservers, use dedicated hardware which is designed to handle ssl.

It is not the server load (1)

Kakao (1626933) | more than 3 years ago | (#34040476)

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?

Re:Let's just encrypt everything all the time (0)

Anonymous Coward | more than 3 years ago | (#34039944)

A wildcard cert can pretty easily deal with the subdomain issue for about $50 a year. The real cost isn't the cert though, it's the hardware to encrypt/decrypt all that traffic, which for a high volume site is not insignificant.

Re:Let's just encrypt everything all the time (1, Offtopic)

Bert64 (520050) | more than 3 years ago | (#34040116)

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).

Virtual Domains don't work with SSL (1, Informative)

Anonymous Coward | more than 3 years ago | (#34040672)

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:Let's just encrypt everything all the time (0)

Anonymous Coward | more than 3 years ago | (#34040462)

I sell SSL certificates too. The only problem is that they're signed by ME, which is usually not a trusted authority.

how about (0, Offtopic)

Spy Handler (822350) | more than 3 years ago | (#34039496)

simply not using social networks?

Re:how about (1)

bhartman34 (886109) | more than 3 years ago | (#34039642)

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.

Re:how about (0)

Anonymous Coward | more than 3 years ago | (#34039748)

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.

They get the "kind of victory", but they miss out on the real victory of identity theft and spear phishing. Go ahead and use unencrypted sites, but have fun explaining to your friends why you sent them emails from Moscow asking for money after being pickpocketed without even leaving your local Starbucks.

Re:how about (1)

bhartman34 (886109) | more than 3 years ago | (#34039830)

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.

Re:how about (1, Informative)

Anonymous Coward | more than 3 years ago | (#34040010)

By default, it doesn't force encryption upon logging in. Even if you go there, it reverts to non SSL on every request.

Re:how about (3, Informative)

rakuen (1230808) | more than 3 years ago | (#34039668)

Guess you're going to have to quit /. because we're using vanilla http at the moment as well.

Re:how about (0)

Anonymous Coward | more than 3 years ago | (#34039798)

I suppose you defend against hackers by not owning a PC, and defend against fraud by not having any money?

Re:how about (1, Funny)

Anonymous Coward | more than 3 years ago | (#34040226)

simply not using social networks?

*gasp* HERETIC!!!

Defense is Easy (5, Funny)

The_mad_linguist (1019680) | more than 3 years ago | (#34039540)

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? (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34039572)

Well geepers Mr. Taco how about https on slashdot?

USB Tethering - safe? (1)

joe2tiger (1883232) | more than 3 years ago | (#34039578)

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?

Re:USB Tethering - safe? (0)

Anonymous Coward | more than 3 years ago | (#34040130)

No, and it is broadcasting in a much bigger range by not using WiFi.

Re:USB Tethering - safe? (1)

indeterminator (1829904) | more than 3 years ago | (#34040144)

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.

Re:USB Tethering - safe? (1)

Lumpy (12016) | more than 3 years ago | (#34040426)

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:USB Tethering - safe? (1)

exhilaration (587191) | more than 3 years ago | (#34040542)

Or if you have Linux web hosting, just use SSH tunneling [google.com] . You're already paying for web hosting, might as well get more out of it.

Re:USB Tethering - safe? (1)

tepples (727027) | more than 3 years ago | (#34040754)

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.

Shell providers (1)

Compaqt (1758360) | more than 3 years ago | (#34040922)

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.

slashdot's method (5, Insightful)

Lord Ender (156273) | more than 3 years ago | (#34039584)

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:slashdot's method (1)

John Hasler (414242) | more than 3 years ago | (#34039838)

What's "private" about anything on Slashdot?

Re:slashdot's method (1)

bunratty (545641) | more than 3 years ago | (#34039904)

You don't mind the GNAA making posts using your account on Slashdot I suppose. And I'm sure future employeers will not mind when they see that stuff posted using your name when they search the Internet prior to hiring you.

Re:slashdot's method (0)

Anonymous Coward | more than 3 years ago | (#34040478)

My current boss knows I used to be affiliated with the GNAA. I even linked him to a press release they made with my nick in it.

Re:slashdot's method (1)

bhartman34 (886109) | more than 3 years ago | (#34039952)

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. What does one really gain by hijacking a Slashdot account?

Re:slashdot's method (1)

DutchUncle (826473) | more than 3 years ago | (#34040356)

The question should be, What damage can one really do by hijacking a Slashdot account? How easy is it for someone to post things with your name and ID that contradict what you've written and make you look bad?

Re:slashdot's method (2, Funny)

betterunixthanunix (980855) | more than 3 years ago | (#34040744)

Oh the horror! You might look like an idiot on Slashdot of all places!

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:slashdot's method (0)

Anonymous Coward | more than 3 years ago | (#34040770)

How about, Slashdot should always use SSL just to help make SSL just a little more ubiquitous, for the public good.
As should every website everywhere, always.

Re:slashdot's method (1)

avij (105924) | more than 3 years ago | (#34040448)

HTTPS works fine here. Perhaps you should consider becoming a /. subscriber if you want HTTPS.

p.s. posted over SSL

slashdot's method (1)

formfeed (703859) | more than 3 years ago | (#34040494)

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??

Good old faithful media.. (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34039612)

as always, all about the yellow journalism. Its nice to know some stuff never change.

That's Expensive (0)

Anonymous Coward | more than 3 years ago | (#34039710)

Encryption is fast, but if you do it for every page view the cost to providers will add up.

Re:That's Expensive (3, Interesting)

IAmGarethAdams (990037) | more than 3 years ago | (#34040060)

Not necessarily true, Google have a solution [imperialviolet.org] which means that

SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead

Re:That's Expensive (3, Interesting)

gad_zuki! (70830) | more than 3 years ago | (#34040628)

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 (2, Insightful)

LordMyren (15499) | more than 3 years ago | (#34040678)

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.

alternative solution (0, Flamebait)

Speare (84249) | more than 3 years ago | (#34039732)

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.

Not a great answer (1)

FranTaylor (164577) | more than 3 years ago | (#34039894)

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:alternative solution (1)

txtracer (191320) | more than 3 years ago | (#34039902)

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.

Re:alternative solution (0)

Anonymous Coward | more than 3 years ago | (#34039962)

Unmentioned is the other obvious and simple solution: don't join onto "social networks."

I'm a pastor and Facebook has become an incredible tool for our ministry. It has proven to be the best way to communicate with many of our members that rarely check email, but are on Facebook everyday. We also are able to keep up better with members who are sick or hospitalized because they often times will post on Facebook first. "Don't join social networks" makes as much sense as "don't have friends." Sure it will save you some hardships, but the benefits outweigh the cost.

Re:alternative solution (1)

DragonWriter (970822) | more than 3 years ago | (#34040006)

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.

ISTR... (1)

fferret (58662) | more than 3 years ago | (#34039800)

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?

Re:ISTR... (0)

Anonymous Coward | more than 3 years ago | (#34039874)

SSL has not been compromised.

Re:ISTR... (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34040200)

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.

Mathematically, no big deal; but in practice, potentially an issue.

Re:ISTR... (0)

Anonymous Coward | more than 3 years ago | (#34040290)

Yeah, I meant mathematically.
Now that I'm curious, who are the dodgey entities?

Re:ISTR... (1)

Amouth (879122) | more than 3 years ago | (#34039928)

if i remember right it wasn't reliable - and relied on guessing rather than pure computational.

Re:ISTR... (0)

Anonymous Coward | more than 3 years ago | (#34040038)

It was a problem with Microsoft's AES implementation in IIS. A faulty implementation does not a broken protocol make.

Linux version? (1)

alexandre (53) | more than 3 years ago | (#34039954)

So uhm, windows and mac only?
I thought we were supposed to be the sniffing ones!

Re:Linux version? (0)

Anonymous Coward | more than 3 years ago | (#34040178)

It's coming soon. There is a pull request [github.com] open right now.

Re:Linux version? (0)

Anonymous Coward | more than 3 years ago | (#34040716)

Looking at the source-code in github, it appears someone has modified it to allow for linux support as well.

Myopic view of how browsers treat SSL (4, Informative)

kamelkev (114875) | more than 3 years ago | (#34040022)

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:Myopic view of how browsers treat SSL (1)

bunratty (545641) | more than 3 years ago | (#34040086)

Do they throw up a warning even when all traffic to one site is SSL and all traffic to another site is non-SSL?

Re:Myopic view of how browsers treat SSL (1)

XanC (644172) | more than 3 years ago | (#34040234)

Whenever an HTTP element (of any kind) on an HTTPS page is loaded, a big hairy warning message pops up.

Re:Myopic view of how browsers treat SSL (1)

bunratty (545641) | more than 3 years ago | (#34040446)

Yes, I understand. But I was under the impression the HTTP element had to be on the same site as the HTTPS page. Is that not the case?

Re:Myopic view of how browsers treat SSL (1)

XanC (644172) | more than 3 years ago | (#34040488)

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.

advice is obvious (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34040040)

Of course the advice is pretty obvious: Don't use free Wi-Fi, use SSL, or a VPN.

How about: don't use social networks.

Obvious... (1)

Bert64 (520050) | more than 3 years ago | (#34040172)

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:Obvious... (1)

ultranova (717540) | more than 3 years ago | (#34040402)

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.

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 (2, Insightful)

tepples (727027) | more than 3 years ago | (#34040696)

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:Obvious... (1)

dme0 (958925) | more than 3 years ago | (#34040624)

The problem is that any form of authentication includes passing a cookie with a session ID, which happens on every request with a site like facebook.

A little paranoia here... (2, Informative)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34040174)

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.

Re:A little paranoia here... (0, Troll)

Lumpy (12016) | more than 3 years ago | (#34040506)

Open WLAN done by garbage WAPs do this. A decent WAP will not make it easy. Ones I install issue a complete seperate IP address and subnet for each connected person... It does not give you security, but it makes it far harder for script kiddie click and hack tools to actually find anything.

"Creates a separate virtual network for your wireless network. When this feature is enabled, each of your wireless client will be in its own virtual network and will not be able to communicate with each other. You may want to utilize this feature if you have many guests that frequent your wireless network."

It's called AP isolation and only a half assed install done by a n00b or wanna-be networking person does not have it enabled. Simply enabling this on a Open WAP castrates the firesheep quickly.

So it's only a problem at places where a complete idiot set up the wireless.

Re:A little paranoia here... (3, Insightful)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34040646)

Given that transmissions from both the AP and the client are in the clear, and generally coming from a reasonably omnidirectional antenna, AP isolation on an open AP doesn't buy you very much.

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.

Re:A little paranoia here... (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34040846)

So it's only a problem at places where a complete idiot set up the wireless.

Or setup by a neckbearded script-kiddie in a coffee shop -- just because there's a properly adminned network doesn't mean you're connected to it.

SSH Tunnels... (0)

Anonymous Coward | more than 3 years ago | (#34040176)

...do it now! Do it!

Redirect to SSL not secure (1)

mysidia (191772) | more than 3 years ago | (#34040206)

big sites should start by redirecting all non-ssl traffic to https automatically.

Haven't you ever heard of SSLProxy or or SSLStrip [securitytube.net]?

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.

Or... (0)

Anonymous Coward | more than 3 years ago | (#34040252)

Delete your social networking profile and talk to people instead. I am 28 and happy I left Facebook.

This FP cfor GNAA (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34040308)

Baby take my = 36400 Fr3eBSD To yet another

If androids dream of electric sheep... (1)

wjousts (1529427) | more than 3 years ago | (#34040326)

Who dreams of fire sheep?

Re:If androids dream of electric sheep... (0)

Anonymous Coward | more than 3 years ago | (#34040662)

Pyromaniacs obviously.

Offtopic question - classic discussion system (0)

Anonymous Coward | more than 3 years ago | (#34040482)

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?

Google cookie stolen from other Google services? (1)

Obispus (803786) | more than 3 years ago | (#34040784)

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...
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...