cdine

Thanks! That was the goal. For those who aren't familiar, the original slides and our response blog posts are still up: https://codebutler.com/projects/firesheep/

Firesheep co-author here. Thanks and agreed :)

Source: https://github.com/SecurityInnovation/PGPy

Documentation: https://pythonhosted.org/PGPy/

For some time I've ran a box with PF forwarding all TCP ports to an SSH server. That plus a simple nmap connect scan has proved handy for countless annoying networks that try to block "common" ports, poorly configured captive portal networks, etc. It's amazing how many "restricted" networks allow TCP 1, 53, 1723, 8080, and a few others out to the open net.

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!

Most sites don't properly invalidate sessions when you log out, you can't protect yourself as well as you think. See our slide on this topic:

http://codebutler.github.com/firesheep/tc12/#18

It's 100% open source! Please feel free to review it.

http://github.com/codebutler/firesheep

It doesn't currently do anything with passwords, it's only pulling out cookies from HTTP Response headers. But it would be trivial to also get passwords in non-HTTPS requests for logins with the same method.

Yup, they're one of our examples of a "good" setup. However, Google leaks iGoogle and some other things (Latitude, address book, reader, ...)

HTTPS Everywhere only works on a select few sites. You're up a creek for anything it doesn't cover.

And Tor, there's lots of cases where operators did bad things. Don't trust it for sensitive information. http://blog.ironkey.com/?p=201

This vulnerability (it hurts to even call it such at this point) has been around for years, and the attack has always been easy for a determined attacker to carry out.

How else are we going to convince people to secure their sites and protect their users? People have been presenting on this issue for years (Ferret & Hamster, Blackhat 2007) and companies haven't responded/cared. It's possible to solve this problem (Gmail is all HTTPS, and done correctly, Amazon has a tiered authentication system that properly uses SSL for important things, Wordpress does SSL right for accessing their admin interface) - companies need to step up and address the issue.

Well, hopefully it will then convince companies to properly secure their websites and actually protect users.

I love SSH tunnels, but in regards to this particular problem, it really just pushes the problem off to wherever you ssh tunnel terminates. Do you trust you server operator? ISP? This is addressed in our presentation, here (VPN's are essentially doing the same thing): http://codebutler.github.com/firesheep/tc12/#20

Sorry if it was misleading somehow, this is definitely not a vulnerability in Firefox. It's a Firefox extension that makes it easy to execute HTTP session hijacking attacks.

They specifically mention that the certificate size (and that of intermediates, among other things) impacts the message size and thus the TCP packet sizes used during handshakes. They actually explain all of this quite well, just read the entire article [specifically the "Certificates" section].

Interesting, thanks for the pre-coffee clarification. aka I can't read =]

I'm sure people will still mess things up :)

So, I get it and all that, what are some real world use cases of this and the postgresql equivalent? Who's actually using these things for something other than saying how fast they are?

I just hope they aren't being used as public-facing JSON API endpoints and the such, since none of them seem to even consider the case of SQL injection. From a quick glance it doesn't seem that any type of parameterized query or prepared statements are available to even begin helping with that, and the "documentation" examples wouldn't be setting people off on the right foot by even limiting the location paths with strict regex's.

This link is actually to an article titled "Legal challenge between Palo Alto company, Orange County hospital halts stem cell research"

This link results in a redirect loop for me, the following seems to work: http://news.yahoo.com/s/csm/20100429/cm_csm/297733

Has anyone else had experience with onlinkbank.com? That's the service which Verity has switched to for their online banking, which uses a single domain for all of their customers it seems (e.g. if You're with financial institution X you access your online banking via https://command.onlinebank.com/X/)

It just looks sketchy, you have same-origin issues potentially, and their UI is horrible leading me to believe they probably don't have high overall code quality.

In addition to setting the passwords as described, they also make the user pad their username with leading 0's because their app can't handle <8 char user names. That's ridiculous on so many levels, I don't need to elaborate why here.