Your Mac and Linux and Firefox will not save you.
The media has pretty much failed to pick up how devastating it actually is, because the writers don't understand SSL well enough to write about it.
Firefox has fixed the null-prefix issue. Microsoft will fix it, too; I don't know why they haven't already (if indeed they haven't, I'm taking these articles' word for it.) Note that when Moxie demonstrated this, Firefox & Linux browsers were all vulnerable, too -- they just fixed it faster, they weren't more secure to start.
But that's not the fundamental issue, just one facet of it. The real issue is that certificate revocation is broken, in its design (i.e. you can't just patch it) and Moxie's sslsniff makes formerly difficult attacks so easy that people can carry them out without understanding them.
Since revocation is broken, if you can get a CA (Certificate Authority) to issue you a certificate, you can use it to carry out attacks like this forever. Someone got a "null prefix" cert issued that works for paypal.com; however, what these articles
don't say is that at Defcon, Moxie was waving around a cert for login.live.com (a.k.a. Windows Live ID or Passport) that wasn't a null-prefix cert -- he convinced a CA to give him a real, perfectly valid, correct in every way cert for it. This will work on every browser there is, forever. There is no way to patch this. He also had a certificate for *, which worked for every website on every browser
except IE. (Technically, IE is "broken" in that it won't take a * cert, but this is one case where the "bug" works in your favor.) I don't know if other browsers have put in checks for * since Defcon, but I doubt it. So why aren't these certs in the news, too? Because Moxie had them as a proof of concept, and kept them for himself -- he didn't post them on the Net for any hacker to use.
So, how did he get these certs? Well, there are some 4,500 certificate authorities, like VeriSign, Thawte, Comodo, RapidSSL, QuickSSL, etc., etc.
Every CA can issue certs for every domain. Now, in theory, they have to verify that you own the domain before they give you a cert for it, and they do this by only giving the cert to the person who has their email address in the WHOIS record for the domain.
Think about that. All the security around SSL depends on
DNS and
email. Gee, there's never been any security flaws in those, have there?
So Moxie found a flawed CA, whose website let him pick which email address to send the cert to. (The idiots who wrote the CA's site checked to make sure the address was allowed in JavaScript, on the user's browser, instead of on the server! Easy hacking.) And he asked it for lots of certs for sites he didn't own, and they gave them to him.
They can't take it back. Those certs are good forever.
So, that CA was flawed, and it fixed this bug. Wanna bet that one of the other 4,499 is flawed, too?
Of course, you don't have to. Why don't you become a CA? You can go to Comodo, and sign up as a Comodo Reseller. It only takes a $200 deposit. That means your site can issue certs, and Comodo's CA signs them. They trust you to validate that the domains are owned by the people you're issuing them to.
THEY TRUST YOU TO VALIDATE THAT THE DOMAINS ARE OWNED BY THE PEOPLE YOU'RE ISSUING THEM TO.
So you just skip that whole validation mess on some certs for yourself, and presto, you have certs for whatever you want.
It doesn't work if you get greedy (there's a blacklist of domains they won't issue to, like *, or verisign.com, or comodo.com, but -- as of Defcon, at least -- not for little unimportant sites like google.com) but it works for most sites.
So, what can you do? Well, the net result of this is that if I (or anyone else, really; this doesn't require super-hacker skills, sslsniff made it easy) want to listen in on your SSL sessions on any network I can man-in-the-middle, I can. Doesn't matter what browser you use, there's no sign on your side, there's nothing you can do at all. So, what networks can I man-in-the-middle? There are two kinds:
1.) Networks I own. If it's my own router, or a router I've hacked into, I can carry out this attack.
2.) WiFi networks that are open or use WEP (which is basically like being open.) I can only do this on a WPA network if I have the key. I can't do this on a WPA2 network that uses 802.1x authentication at all.
Short-short version: the only way to be safe is to not rely on SSL on an untrustworthy network. Either only use really important sites from networks you trust (e.g. wired network at home), or VPN into a network you trust when you're on an untrustworthy network. (Ironically, SSL VPNs are subject to these same attacks; you'd have to use an IPsec or PPTP/ISTP VPN.)
