Live data from Hacker News

Firesheep: Easy HTTP session hijacking from within Firefox

codebutler.com

181–190 of 356 posts

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#181

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…

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 defend against any kind of XSS, so it's pretty meh. Or is there some kind of meta tag etc. that enforces same-origin? (If not, that would be a cool addition. Maybe a list of allowed domains?)

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#182
post #13

Nice . A solid demonstration to show next time your webmaster doesn't want to set up SSL everywhere. That said, the current cartel-like setup of certificate authorities (protection money and everything!) makes SSL annoying and expensive if you want the browser to not have a fit. Especially for small-scale projects. But there's really no excuse for larger sites.

HTTPS also needs distinct IP addresses for distinct hostnames, so that the HTTP handshake, in which the Host: header appears, is already protected by an encrypted channel. No more having multiple websites on one IP address.

There's TLS 1.1 SNI extension which adds vhosts.

Works — of course — everywhere except IE6/7XP.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#183

What does this mean for HTTP basic authentication? How about digest access authentication?

Basic is useless - sends password in the clear.

Digest authentication is safe against passive sniffing (it doesn't exchange any password/token in the clear and uses nonces), but it doesn't protect against active attacker who could modify server headers and replace "Digest" with "Basic" to reveal password.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#184

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…

> How many new servers are going to be needed now that https is used for everything and requests can't be cached?

Wrong. You don't need to use https for everything -- you can specify a domain and a path in the cookie. For things like images, videos and css, you still don't need SSL.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#185
post #68
post #46

Earlier quoted context omitted.

Require SSL on any request who's response sends a set-cookie http header. Leave it out for the non-sensitive request/responses.

You'd still be able to get the cookie when the client sends it bnack to the server on subsequent, non-SSL requests. It's gotta be SSL all the time.

[deleted]

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#186
This is one of many reasons Loopt has used SSL for all[1] traffic from the very beginning. At least WiFi has fairly limited range. Cell networks[2] (and satellite internet[3]) can be sniffed miles away.

In addition to making session hijacking harder, using SSL keeps crappy proxies from caching private data. Remember when some AT&T users were getting logged in as other users on Facebook's mobile site? The cause was a mis-configured caching proxy.

Raising awareness of issues like this gets them fixed. Until a service's users demand SSL, it won't be offered. Unless the service is Loopt :) It's not a noticeable computational burden, but it does increase latency and cost money (for certs).

  1. Not images
  2. Older GSM crypto can be hacked in real time with rainbow tables now
  3. Usually not encrypted at all

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#187

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…

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…

http://stackoverflow.com/questions/954327/hidden-features-of...

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#188
post #186

This is one of many reasons Loopt has used SSL for all[1] traffic from the very beginning. At least WiFi has fairly limited range. Cell networks[2] (and satellite internet[3]) can be sniffed miles away. In addition to making session hijacking harder, using SSL keeps crappy proxies from caching private data. Remember when some AT&T users were getting logged in as other users on Facebook's mobile site? The cause was a…

Indeed, Loopt appears to be one of the few high-profile sites to have done this right. SSL for everything, and cookies that are relevant to login sessions are marked secure. This is what we need everywhere!

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#189
post #174

For anyone who has SSH access to a server (but not VPN) and is wondering what to do when you need some security in a pinch, here is a quick fix... Open an ssh connection to a server you have access to using something like the following: ssh -ND 8887 -p 22 rufus@12.120.186.8 where 8887 is the port on your laptop that you will tunnel through, -p 22 is the port the ssh server is on (22 is the default but I use a differe…

I'd like to buy such a server at low purchase and maintenance cost. The Pandaboard[1] looks like a good fit, but the instructions to install a Linux distro are a bit scary [2]. I guess I could do it, from my Mac, but I'm a bit afraid to mess things up with the low-level disk utilities. Does someones sells SD cards with a distro pre-installed? Or an equivalent device with an easier setup? If not, there's probably a ma…

There are lots of dirt-cheap Atom-based Mini-ITX systems out there. A basic motherboard with CPU will cost you about €60, a bit more for a dual-core. You can probably scavenge some DDR2 ram from an upgraded laptop and install the OS on a USB stick. Mini-ITX cases/PSUs tend to be cheap too. If this going to sit in your office or home, you might want to watch out for noise/heat with both motherboard and PSU and pay a bit more for a fanless motherboard & PSU and get a case with a large, slow-rotating fan. All in all you can probably come in under €200 plus a multiple of that for your time for research, assembly and installation. Or just rent a VPS.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#190
Thanks for posting this. It convinced me to upgrade SSL support from "something that would be nice to implement if I was bored someday" (BCC is not exactly security critical -- except, on reflection, the admin pages) to "drop everything and get it done."
Post reply on HN