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!
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.
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.
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].
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.
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.