Slashdot Mirror
Black Hat Presentation Highlights SSL Encryption Flaws
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."
Come on, this does not highlight vulnerabilities of SSL, but errors in implementing it for specific platforms. This was always a weak point.
It's a problem with sites that start out with http://example.com/ and then transition to https://secure.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.
"It doesn't cost enough, and it makes too much sense."
You simply misunderstood the summary - It's fine the way it is.
Independent hacker Moxie Marlinspike showed off several techniques to get fool the tech behind the little padlock on your screen.
"fool the tech" is a little bot that hides behind the padlock on your browser, watches what you're typing, and reports it back to Moxie. Moxie has several techniques for getting Fool behind the padlock. Why Moxie named the little tech Fool, I have no idea.
He's getting rather old, but he's a good mouse.
If you are going to criticize someone's grammar. Your post should be grammatically flawless. And your post isn't. That's laughable.
"I thought you editor's had better standards."
If you don't implement the security, you're not secure. The author claims that some browsers don't check to see that an intermediate certificate is actually authorized to sign other certificates. So naturally there's a simple attack based on that, but it doesn't really show a flaw in SSL.
The author also complains about companies which post secure forms on non-secure pages, which is a valid complaint but is also a case of "You're using it wrong" rather than a problem with the protocols. Most users are never going to check for the lock (or whatever), so the basic problem will be with us forever, but banks don't have to screw it up by putting login forms on non-secure pages normally. Yes, it's convenient to have a login on a home page, and yes it would consume too many resources to make every home page hit into an https hit, but security ought to count for something, particularly with a bank.
Reminds me of the first lesson in hacking: Social Engineering is More Powerful than Passwords. Only the other way around. If you learn what hackers do, you can avoid them (most of the time). And if their is a Master Hacker who can dupe me, I doubt their is much I can do to stop him. Thankfully I'm not important enough to be a target.
We are the Borg...
If YOU are going to. criticize someone else's. Grammar. Don't use sentence fragments to do. It.
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, PDF file) is "people don't type 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?
Colorless green Cthulhu waits dreaming furiously.
End-to-end encryption is required at all levels of the internet. Until that is available, the internet will never be secure, because someone will be able to read the non-encrypted data you send and reply with a fake response.
Thankfully I'm not important enough to be a target.
A common myth, based on a belief that "hacking" is done by some smart guy sitting around thinking about which "important person" to go after next.
The answer (if you're smart enough and slightly lazy) is "why not everyone?" or at least "anyone that falls into the trap". An automated program doesn't really care who you are, if you're "important" or not. Only that it can trick you into losing some money. Personally I think that's why a lot of people fall for 419 scams.
AccountKiller
Shatner, is that you?
"Physics is to math as sex is to masturbation." -R. Feynman
What? I mean, are online businesses down in their underground lairs, laughing at the misinformation perpetrated on an unsuspecting public? "Hah! They believe that SSL encryption is secure!"....
Maybe it should be "...isn't as secure as online businesses would like it to be." I think that it is in the interests of businesses as well as their customers for SSL transactions to remain secure. We can address incompetently implemented security protocols without treating it like a conspiracy on the part of the sites...
I am the man with no sig!
My biggest gripe about these black hat papers is that they aren't as useful to non-black hats; there are no proposed solutions or workarounds.
I think the most important trick in the paper is that first one you mentioned, of MITM translating server-side SSL to client-side plain-text and assuming the reader won't notice (or care). The easiest workaround is to get Firefox to return the yellow background. You still have to train users to mentally require it, but it's a step in the right direction.
On to the second hack you noted. The article specifically mentions that .com and several other top level domains (TLDs) are purposefully punycoded (see page 90). However, the logic is still sound and the actual TLD doesn't matter. The example Moxie used was *.ijjk.cn.
A solution proposal (from the top of my head): In the specific case of IDN-valid characters that approximate slash and question-mark, the simple solution is to propose a feature in firefox that recognizes them. Specifically, anything that appears to be forging a protected TLD, so punycoding IDN domains matching a regex like \w\W+(com|net|org)\W (and perhaps additionally a search for any of the proposed confusing characters), would cover a lot of ground. In the meanwhile, you could put the domain up in firefox's blue SSL box.
The final vulnerability discussed in the paper (the first one in the paper's ordering) was that of standard certificates acting as intermediate certificates in the chain. This has an obvious solution and the paper even implies (but doesn't verify ... freaking black hats) that Firefox already has it implemented.
Use my userscript to add story images to Slashdot. There's no going back.