Black Hat Presentation Highlights SSL Encryption Flaws 152
nk497 writes "Hackers at the Black Hat conference have shown that SSL encryption isn't as secure as online businesses would like us to think. Independent hacker Moxie Marlinspike showed off several techniques to fool the tech behind the little padlock on your screen. He claimed that by using a real world attack on several secure websites such as PayPal, Gmail, Ticketmaster and Facebook, he garnered 117 email accounts, 16 credit card numbers, seven PayPal logins and 300 other miscellaneous secure logins."
It's not a problem with SSL /per se/ (Score:5, Interesting)
It's a problem with sites that start out with http://example.com/ [example.com] and then transition to https://secure.example.com/ [example.com].
If I read it right, encrypt it all, turn off http except as a 301 redirect to https and you should be fine. Anyone confirm this?
Course, you still should check the certificate is the one you're expecting.
Re:It's not a problem with SSL /per se/ (Score:2, Interesting)
Re:It's not a problem with SSL /per se/ (Score:3, Interesting)
No, that will not fix this attack. I have not been able to find a copy of his tool online yet, but I am going to assume that he did it right.
This tool should still be able to pull down the html from the https the website, and present it to the user as an http site. No amount of javascript, HTTP redirects, or a href="https:// ... is going to save you in this case. The MITM proxy is always going to be able to strip any of that out, and replace it with something that keeps the clear session alive.
The way to fix this is to change the way firefox implements SSL. Once firefox has visited a website using SSL, firefox needs to automatically connect to SSL, and never trust unencrypted data from that site again. Even that won't help for websites on the first visit. I think firefox should also give big fat warnings if you attempt to POST a password field over an unencrypted channel (that means you slashdot). Furthermore, I am of the opinion that the SSL fingerprint should be cached at that moment as well, so the user can be warned if the cert ever magically changes. This would protect against the possibility of malicious people getting their hands on a root CA.
People don't type https:// (Score:5, Interesting)
One of the claims from the presentation (linked in TFA: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf [blackhat.com], PDF file) is "people don't type https:/// [https]" -- they reach SSL-enabled urls either by submitting a form (from non-SSL page!) or the result of HTTP redirect. And "that has made all the differences" according to the hacker.
Maybe we need a special TLD for HTTPS-only traffic. Let's say ".s". For a given URL, if the hostname is of ".s" domain but the protocol part is not "https:" (or other secure protocols) then the URL is invalid by standard. A browser should be mandated to use HTTPS for such a host if the URL is given incomplete (e.g. user typing "example.s" rather than "https://example.s/" in the Awesome Bar). It should also fail to use a non-secure protocol even if it's available for a ".s" site during any phase of communication.
I don't think this idea is good enough but it's the first thing coming to my mind..
Also I'd like to know more about another exploit mentioned in the presentation.. the failure to check the "Basic Constraints" field of a SSL cert. Is Firefox vulnerable?
Re:It's not a problem with SSL /per se/ (Score:3, Interesting)
If I read it right, encrypt it all, turn off http except as a 301 redirect to https and you should be fine. Anyone confirm this?
Not really. You've only shifted the problem into one of intercepting and modifying the 301 redirect, from intercepting the individual links.
You could turn off http entirely, but then you'll get people complaining that your website doesn't work from the vast majority of people (hell, including me really).
This is really a browser problem, and a user problem. One way to fix this would be for the browser to recognize sites (domains really) that should be HTTPS ONLY, and refuses to use HTTP when going to them. I.e. the user types, clicks, or uses a bookmark to go to www.mybank.com, and instead of the default http, it goes to https. If it encounters a non-http link for that domain, it simply disobeys (or puts up a huge warning flag).
Re:People don't type https:// (Score:3, Interesting)
I wonder how practical this would be? I think it would be easier to "bolt-on" than using a new TLD, but would it be more vulnerable to DNS spoofing than using a new TLD?
Pop-up is bad, telling the user is good (Score:4, Interesting)
If browser makers simply gave pop-ups
No. No no no! Death to pop-ups.
And here's why: they interrupt you in what you're trying to do. If they surprise you, you feel less in control of your environment which is bad (see http://en.wikipedia.org/wiki/Learned_helplessness [wikipedia.org] and http://en.wikipedia.org/wiki/Locus_of_control [wikipedia.org]). If they don't they're pointless because you'll already know in advance what your answer is going to be, so why can't you just tell the program what your answer is when you tell it to go do whatever made it interrupt and annoy you?
A better solution is the slide-down bar which you probably know from using firefox. Instead of being in your way, it steals a little screen real estate near the edge and uses a color to tell you "you might want to pay attention here" without being in the way of what you really want to look at. Something similar happens when gedit and evince encounter an error.
They're much better than pop-ups, in the cases where you have enough room for the text you need to display to the user.
But you-the-browser probably should tell the user "Your password will be sent to $OTHER_DOMAIN. This is likely to be a security problem", so use a slide-down bar for this.
He makes some good points (Score:3, Interesting)
I remember a few years ago banks (and others) were trying to "educate" people about not forcing https connections to their main pages for login purposes. Their explanation was "our login forms submit to a processing script that runs on https, so there's no problem". Well, one thing Moxie demonstrated is an effective way to attack this exact sort of situation via MITM.
I do take issue with his statement "no one types in https (or http for that matter)". With many people he's correct; but I know I do pay attention to this, and I try to get my family and friends to do so as well. Also (especially nowadays) people need to start paying attention to whether they're in situations where MITM is made much easier, such as on unencrypted wireless networks.
Re:God forbid... (Score:3, Interesting)
I think he was talking about people specifically trying to break into his box, presumably a server. Like him, I don't really think my server is that juicy a target. A determined hacker *can* break into it, no argument. But it's got enough of a deterrent in place, in the form of frequent updates by a sysadmin who subscribes to the mailing lists for all the software she's running, requiring SSH to log in, the non-existence of any remote administration tools except for SSH, only allowing one user shell access (unfortunately, I'm on a dynamic IP, else I'd be restricting it to IP as well), and said user having a password that expires every 30 days, to make it an unattractive target for that kind of attack.
When it comes to viruses, trojans, and other forms of malware, you're absolutely right. The human will always be the weak factor, and the software doesn't give a damn what human it's targetting. A little bit of common sense and a little bit of knowledge about how these kinds of things work will do wonders to protect you from harmful attack. But when it comes to securing a server against intrusion, it's not about preventing attack: there's nothing you can do short of taking the server offline to 100% guarantee that it won't be attacked. It's about making it enough of an annoyance to break into your computer that anybody who doesn't have a personal vendetta will go after an easier target.
Re:Oh god (Score:2, Interesting)
Firefox even has everything needed to defeat this already built in - it's just not enabled by default. By setting browser.identity.ssl_domain_display to 1 in about:config, it displays a blue strip left of the URL with the last two parts of the domain name, similar to the green strip with the registrant's name for EV certs.
They should enable this by default, and whoops, the iiijk.cn attack described in the PDF is instantly obvious.