Live data from Hacker News

Firesheep: Easy HTTP session hijacking from within Firefox

codebutler.com

71–80 of 356 posts

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#71
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.

You can get SSL certificates for free for one domain, and they work with all browsers (except Opera, IIRC). Also, you can use Perspectives for Firefox, which I think is much better than the current system.

The monkeysphere is also a good alternative if you use debian and gpg.

http://web.monkeysphere.info/

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#72
post #44

Earlier quoted context omitted.

Check historio.us, the ssl cert there is a free one (which is, sadly, why subdomains don't validate). AFAIK this is common to all certs (free or otherwise). You need a separate one for each subdomain (including www).

No, there are also wildcard certificates that match all subdomains, but are rather more expensive.

Didn't know that, thanks.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#73
post #47

This is kind of a big deal. Not a whole lot of people are aware of this vulnerability and among those who are it's likely only a small subset that knew how to exploit it until now. I suspect all of the coffee shops in the college town where I live will have people using this starting tomorrow. I've personally been working from cafes and tunneling everything through SSH for years, but in my experience almost no one el…

I've personally been working from cafes and tunneling everything through SSH for years To where? I suspect it's to a server, VPS, or similar, and the connection is unencrypted from there to its endpoint. This being the case, could someone with a server on the same subnet be running a browser remotely (or even just tcpdump) and doing a similar thing with your logins? (This is just some thinking out loud and I may be t…

Virtually no modern wired networks use hubs anymore, they're for the most part switched. Unlike wireless networks where packets are broadcast freely in to the air, the switch checks the destination address and sends the packets only to the endpoint. There are some attacks like arp-spoofing and flooding which can defeat this, but they don't work well against modern enterprise-grade switches like you would find in a data center.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#74
post #44

Earlier quoted context omitted.

Ah, I can't remember the name now... Rapidssl? That's probably it. Check historio.us, the ssl cert there is a free one (which is, sadly, why subdomains don't validate). EDIT: I searched and it's actually http://cert.startcom.org/ .

Check historio.us, the ssl cert there is a free one (which is, sadly, why subdomains don't validate). AFAIK this is common to all certs (free or otherwise). You need a separate one for each subdomain (including www).

[deleted]

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#75
post #56
post #37

The explanation I've always heard for not using HTTPS 100% of the time is that it puts an substantial load on the server, and for many sites it's overkill. Setting aside the subjective topic of "overkill" ... how much more CPU-intensive is it to serve pages over HTTPS compared to HTTP?

The CPU intensive part of a HTTPS connection is the initial key negotiation/session setup (using asymmetric encryption methods). The symmetric encryption of the actual traffic is pretty trivial. You can amortise the session setup cost by ensuring the HTTPS session caching is enabled on your server (in Apache, the directive is SSLSessionCache). This will let subsequent connections from the same client re-use the same…

ooh, SSL DDoS

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#76

Earlier quoted context omitted.

On Mac OS X, it gives an error saying: Run --fix-permissions first. Run with which command? and how?

I found the binary "firesheep-backend" in: ~/Library/Application Support/Firefox/Profiles/ .default/extensions/firesheep@codebutler.com/platform/Darwin_x86-gcc3 I ran both: ./firesheep-backend --fix-permissions and sudo ./firesheep-backend --fix-permissions and it still asks me to run it with "--fix-permissions". I guess it's time to go digging around in the source to try and find out what it wants me to do. EDIT: Af…

There is an another firesheep-backend at /firesheep-backend.dSYM/Contents/Resources/DWARF inside the Darwin folder. However this one wont run using ./

Any ideas?

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#77
post #57

Earlier quoted context omitted.

You can get SSL certificates for free for one domain, and they work with all browsers (except Opera, IIRC). Also, you can use Perspectives for Firefox, which I think is much better than the current system.

Right, and even the paid ones can be had for well under $30/yr nowadays, which is pretty trivial.

There are levels of pay for functionality, like subdomains, and being able to issue your own certificates.

For instance, from Verisign: a 1 year Microsoft code signing certificate starts at $499 [1]. A top-of-the-line (from their main pages) web certificate for a single server for one year: $1499 [2]

[1]: https://securitycenter.verisign.com/celp/enroll/selectOption... [2]: https://ssl-certificate-center.verisign.com/process/retail/p...

edit: it would figure the links don't work. Just go to www.verisign.com and those are a couple clicks from the front page.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#78

Earlier quoted context omitted.

The cpu load can be mitigated with frontend https accelerators or proxies (think nginx as a load balancer doing the https). The real problem is the first connection. Browsers don't fall back to https, if nothing answers on http they'll give an error. If the first connection is over http then a man in the middle attack can succeed.

> If the first connection is over http then a man in the middle attack can succeed. There are ways to work around this, if the non-https site immediately redirects to the https version and a "secure cookie" (https-only) is exchanged afterwards.

Someone correct me if I'm wrong, but that's the exact vector point for a man-in-the-middle attack. First request over HTTP gets hijacked, redirected to a "secure" server, then you (the user) see the lock and go to town, secure in the knowledge that you're communications with this server are protected because they're encrypted.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#79
post #56

Earlier quoted context omitted.

The CPU intensive part of a HTTPS connection is the initial key negotiation/session setup (using asymmetric encryption methods). The symmetric encryption of the actual traffic is pretty trivial. You can amortise the session setup cost by ensuring the HTTPS session caching is enabled on your server (in Apache, the directive is SSLSessionCache). This will let subsequent connections from the same client re-use the same…

ooh, SSL DDoS

That possibility is why it would be nice if client puzzles were part of the SSL protocol.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#80
post #24

The sidebar is not showing up for me after installing and restarting. Firefox 3.6.11 OS X 10.6 firesheep-0.1-1.xpi

Same setup. Sidebar shows for me after selecting it from the View -> Sidebar menu, however it pops up with a message that says "Run --fix-permissions first." Not sure where I'm supposed to run this flag.

Ditto
Post reply on HN