Live data from Hacker News

Firesheep: Easy HTTP session hijacking from within Firefox

codebutler.com

341–350 of 356 posts

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#341
post #207

Earlier quoted context omitted.

Butler has not raised the threat level on anything. This has been a widely known issue since forever . A friend of mine wrote a sniffer that could do this back in college, and he was one of the last to the party. Want something else to kvetch about? His tool could impersonate the router and act as a proxy, including serving up ssl-encrypted pages to users who didn't realize they shouldn't accept certs from unknown si…

24 hours later, more than 150000 downloads. I believe it is safe to say the threat level has indeed been raised. http://github.com/codebutler/firesheep/downloads

For a public wifi user, how do those 150k downloads actually affect the probability that someone else on the network is using a session-hijacking tool? Given that it was already high enough that people should have already been taking preventative measures, any increase you can attribute to this would still fail to justify the witch-burning you're looking for.

There is zero difference between what someone using public wifi should be doing today and what they should have been doing last week. Now at least more people are aware of the problem.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#342
post #241

Earlier quoted context omitted.

How many new servers are going to be needed now that https is used for everything and requests can't be cached? The main thing holding us back there are browsers that go apeshit if you load images via HTTP on an HTTPS page. Requiring JavaScript or other active content to be loaded from the same HTTPS server would be a good thing in many cases. I think currently ANY https server is allowed, which doesn't actually defe…

FWIW, non-JS is still a vector. For example, img tags can stomp on cookies. Yes, serving static media over SSL is diminishing returns, and it would suck for mid-stream proxies (and every ISP will hurt from it). But don't argue that it doesn't matter from a security perspective.

When done correctly, it should at least avoid this sort of cookie stealing scenario, though - HTTPS-only cookies won't leak into HTTP requests for non-active content, though malicious Set-Cookie: injection into the HTTP responses can obviously log the user out, etc. and may even reveal unwanted info if the HTTPS server doesn't handle the situation gracefully.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#343
post #192

Earlier quoted context omitted.

It doesn't work on my late 2009 MBP (sniffs sessions from other browsers on my laptop but not other laptops on our wifi).

are you sure you aren't on a WPA encrypted network? My understanding is that it doesn't work over WPA. WEP apparently does work though.

I'm on an open network (no security) and I too am only seeing traffic from the computer I'm running it on. I have two Macs on the same wifi network, but no luck so far =/

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#344

Earlier quoted context omitted.

It used to be so, but newer servers can now serve more than one HTTPS domain using the same IP. For more details, check out http://serverfault.com/questions/109800/multiple-ssl-domains...

Newer servers can serve more than one HTTPS domain using the same IP... to users who are not using IE/Chrome/Safari under Windows XP . If you depend on SNI, you're leaving out something like a third of your user base.

Thanks. There really isn't anything more dangerous than just a bit of knowledge.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#345

Earlier quoted context omitted.

Also, remember that some programs don't respect the system's proxy settings and instead use their own. Firefox is one of those, you can find its proxy settings in "Advanced -> Network -> Settings"

alanstorm of stackoverflow answers that deal with Magento fame (well, fame being a relative term but famous to me, anyway)?

Yeah, I'm that Alan Storm. NOT the WCW scrub wrestler.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#346

There are probably going to be a lot of people negatively affected by this for quite some time to come. One thing to point out is that there are grades of things. There is "public", and then there is "top hit on Google". Similarly, there is "insecure" and then there is "simple doubleclick tool to facilitate identity theft". How many millions of dollars and man hours is it going to take to lock down every access point…

As said before, these tools [edit: the stupidly easy point & click ones, btw] have already been available for about 3 years. (e.g. http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3...)

Butler isn't doing anything earth-shattering, he is just reminding everyone AGAIN that the current system is messed up.

There will always be this debate about disclosure, but you can't ignore that it works. Sure, innocents suffer (and they would[they are!] anyway), but at least it's one more reason why websites should change to https.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#347
post #225

Earlier quoted context omitted.

The intersection of 'evil enough to do something truly malicious', 'read a tech blog in the right 24-hour period', 'didn't already know the problem existed', and 'in enough cafes to pair with enough potential victims' is too low to cause "millions" more to be impacted by this, I promise. Your implicit definition of 'highly motivated' (someone willing to put in 5 minutes of Googling) makes me sad. I'm agitated because…

It might make you sad, but it's spot on. People were sharing MP3 files on usenet pretty easily, back in the day. It would have taken 5 minutes or less to work out how -- even easier than grabbing cookies. It wasn't until Napster made that 0 minutes of googling that MP3 filesharing really took off. For something like this to end up on millions of desktops, you have to be able to explain it to a half-stoned frat at a p…

> It wasn't until Napster made that 0 minutes of googling that MP3 filesharing really took off.

(a) network effects (b) autosharing, spurring more (a)

Neither of these apply here.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#349
post #214

Earlier quoted context omitted.

As long as only the minimally motivated can exploit it, it's not really a problem, gotcha. How about instead of shooting the messenger, you take some of that righteous anger and point it at the companies with millions/billions to spend who have simply ignored a longstanding known issue?

How about you recognize that there are a lot of innocent people who will be hurt by this stunt? There are hundreds of thousands of companies and millions of people who are targets for this, and most don't have a spare million lying around. Hospitals, nonprofit groups, anyone running a website has to drop everything to lock it all down now. The effect is a lot like loosing a new virus (and might ultimately be treated…

Re: "Hospitals, nonprofit groups, anyone running a website has to drop everything to lock it all down now." That simply isn't true. Unless a site uses cookies AND firesheep can understand those cookies, the site doesn't have a worse problem today than it did last month. It would be very nice if every site, of every group, implemented SSL for anything remotely personal. But from what I've read I doubt firesheep poses an additional threat to any such not mega-popular site.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#350
post #255

The main problem will be with SaaS apps that allow custom domains names (i.e. mywebsite.com instead of mywebsite.mysaasprovider.com ). I made an early decision to enable SSL everywhere in Trafficspaces with the obvious downside being that I need to allocate a dedicated IP address each time someone requests a custom domain name. I used to get worried that perhaps it would have been better to only provide SSL in specif…

Wouldn't it be easier to get a wildcard SSL certificate for *.mysaasprovider.com? That way you can serve all subdomains off a single IP address, since the name will always match.

That's what we are currently doing now.

I was referring to cases where the account holder wants to use an custom domain name e.g. ads.mywebsite.com, instead of the generic mywebsite.mysaasprovider.com.

In that case, we'll need to host their certificate within our Pound load balancer and get it to listen on a dedicated IP.

Post reply on HN