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."
Hacking (Score:3, Insightful)
It's always about getting the fool.
Sounds like OSI level 8 error (Score:5, Insightful)
God forbid... (Score:3, Insightful)
...hackers and phishers ever take a third-grade English class.
Typos, grammar errors, and awkward Google transalations probably do more to alert average users to scams than SSL certificate warnings.
OK, so don't implement the security. (Score:5, Insightful)
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.
Re:It's not a problem with SSL /per se/ (Score:5, Insightful)
It looks like there are a couple of things, but their main one is a man-in-the-middle attack based on the user not paying attention to the browser's SSL flags. See the difference between page 61 and 62 of their presentation: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf [blackhat.com]
They show on page 69 how it looks once they substitute a lock image for the favicon (if they had wanted to be Extra Evil, they'd have given their fake favicon a blue background, which would have made firefox 3 look exactly like it was SSL protected, except for the S missing in the URL)
They then proceed to show how allowing unicode in the hostname continues to confuse and confound people. Register a cert for *.foo.com, then set up a hostname of www.google.com[unicodeslashlike]login[unicodeslashlike]blah[unicodeslashlike]blah[unicodeslashlike]blah.foo.com and presto, you have a valid certificate for a site that looks more or less like https://www.google.com/login/blah/blah/blah.foo.com [google.com], except that it's not hosted by google.
Basically all of these are attacks on the end user, what you do or don't do on the server won't change a thing.
Re:It's not a problem with SSL /per se/ (Score:3, Insightful)
You are almost right. It is a combined flaw of both browsers and web site implementations. If just one of the two were flawed, it wouldn't be a major issue. But since both are, even security-conscious users are likely to get duped by this.
So many engineering disasters rely on multiple little things going wrong simultaneously...
Re:It's not a problem with SSL /per se/ (Score:5, Insightful)
What exactly is wrong with that? I'm sure that someone can write a script for FF that will detect the error and automatically add the 's' and resend. People had to get used to typing http://www/ [www] in the first place. It's not such a huge jump to add the 's'.
This is the same argument that I see with switching to Linux: oh, users will have to relearn things, it's different than Windows. Yet those same users have to relearn when they get a new cable box and remote. They have to relearn when they get a new microwave. They have to relearn when they get a new television. They have to relearn when they change banks, and on and on and on. It's a lame argument.
In the end, users in general are uninformed, lazy, and lack the drive to become well versed in computer security. SSL encryption issues are hardly the biggest security flaw in computing today. The biggest security flaw is between the ears of the end user. SSL issues hardly register on the list of problems behind the spread of the most devastating malware we know about today.
meh
Re:God forbid... (Score:5, Insightful)
End to end encryption for a safe internet (Score:5, Insightful)
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.
Re:God forbid... (Score:5, Insightful)
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.
Re:The problem is with the trusting user, and can (Score:2, Insightful)
RSA encryption and authentication is the difference
You can't expect the user to do RSA authetication using a keyboard
But the chip in the smart card does exactly that.
Re:OK, so don't implement the security. (Score:1, Insightful)
Odd choice of words (Score:5, Insightful)
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...
Re:Oh god (Score:4, Insightful)
You are absolutely wrong. SSL is not flawed. The UI browsers have implemented regarding SSL is flawed. The UI should make it clear to the users exactly where they are sending their information. It should also make it clear when they are submitting a password over plain text.
Here are some solutions (Score:5, Insightful)
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 [cnet.com]. 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 [cnet.com].
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.
Re:God forbid... (Score:3, Insightful)
Part time job as an accountant. Volunteer work with Deaf people the rest of the time. Live in a one bedroom apartment with my wife. Nope, not important.
A hacking program designed to find exploits in your computer, at your ISP, or any of the internet infra-structure between you and doesn't really care how "important" you are. It only cares about the logic with which it was written.
Your internet connection is only the most easy thing to steal. If an automated program (you can call it a "virus" or "worm" if you really want) can get somewhere within the infrastruture, anytime you use a credit card, the CC# could be stolen. Do you ever bank online?
Importance only matters when an attacker has to pick and choose his targets do to a limit on his own attention. When the computer does the attack for him, "important" is irrelevant, and "ability to exploit" and return is a much bigger factor.