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."
Someone fix the summary before my brain melts.
Independent hacker Moxie Marlinspike showed off several techniques to get fool the tech behind the little padlock on your screen.
What do you command, master...
It's always about getting the fool.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
Come on, this does not highlight vulnerabilities of SSL, but errors in implementing it for specific platforms. This was always a weak point.
Maybe the bad guys are busy elsewhere... wait...
-Woof woof woof!
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."
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."
...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.
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.
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.
he needs to spend some time in jail as a reminder of how to work within the law
Don't be so clueless. Half the people at Black Hat are Feds. Reasoned accommodations were solidified years ago.
Woooooooosssssssshhhhhh!
Yeah, it should be, "I thought you're editor's had better standard's."
This is the same guy who published the infamous basic constraints IE vulnerability a few years ago. His website and the software is www.thoughtcrime.org
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.
People click fake urls in their email, and provide their bank credentials to phishers.
The problem is that bank's website forces the user to authenticate themselves but currently there's no mechanism to force the website to authenticate themselves to the user.
The solution: Smart Cards (e.g. Credit Card with a chip) and Smart Card readers. Or a USB device doing the same; i.e. a fob
Of course the banks will have to spend a few bucks to provide that to their customers; currently it probably is cheaper for the bank to insure and stick the bill to the customer.
Yet another fine example of irony, present on 90% of the ./ posts that complain about spelling, grammar, or both.
You bet we worship them...
Now that this is "out" (publicly anyways, probably been around for awhile) it can be resolved.
Besides, has anyone ever asked you to drive their car somewhere before? did you decide to take it to a chop-shop instead? or sell it?
Ever broke into your neighbours house and stole their stereo, just because you know they don't bother to lock the door?
Ever been waiting at the counter in a store/office/etc, and seen someones information? did you use their creditcard number? did you try and steal their identity?
Did you ever do that, then announce it publicly over 3 different types of media?
(Well, okay, sometimes they're using WEP or ROT13 or memfrob, but in general...)
The World Wide Web is dying. Soon, we shall have only the Internet.
What's the difference between data sent from the keyboard and data sent frm a smart card ?
If it still has to be transfered it doesn't matter what peripheral created the signal.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
How do I actually verify the authenticity of a certification. For ex. if I go to mo bank's site I get the SSL enabled and yellow url bar and can look at the details of the cert. Issued by / to etc.. it also has a MD5/SHA1 - can I just go to verisign.com and look up that cert and compare the MD5/SHA1? The only thing I came up with on their site is a way for webmasters to check their installation but it seems to require Flash - which is a no go.
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.
I'm going back to pen and paper to send mail, then there's no encryption for hackers to break!
Shatner, is that you?
"Physics is to math as sex is to masturbation." -R. Feynman
But where do you use your smart card? I don't think i've ever seen an actual reader in person.
Can you be Even More Awesome?!
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 and http://en.wikipedia.org/wiki/Locus_of_control). 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.
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!
This doesn't seem to me to be as serious as it might sound. You don't actually sites with this method, the attack is against the users of a compromised LAN who are trying to connect to the secure sites. That limits the scope of a real attack to networks in which a tool like sslsniff can be run. That means the attack is either from an internal user, or someone who has been able to compromise a box on your network. Home users should be relatively safe, unless you can spoof DNS or trojan their systems.
What a disgusting display of English grammar. Come on, Slashdot! I thought you editor's had better standards
Oh look, the iron "E" is back.
Free Martian Whores!
If you're handling credit card data at least, you should (better) be familiar with PCI-DSS. Basically, the credit card industry has gone to great lengths to set standards that can simply be followed to help assure that you're NOT handling data (or HTTP) in an insecure manner.
It's amazing what proper due diligence can do for you. It's also amazing how many people think because they CAN take credit card data online, that they automatically should.
"The large print giveth, and the small print taketh away" -- "Step Right Up", Tom Waits
http://en.wikipedia.org/wiki/SecurID
No reader is needed.
Er... please mod down, make fun of, and otherwise disregard the parent comment. And this one, too.
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.
#DeleteChrome
The problem is that bank's website forces the user to authenticate themselves but currently there's no mechanism to force the website to authenticate themselves to the user.
No, the problem is that the user is sending their creds to the bank instead of verifying their creds.
Instead of sending your username + password over an encrypted channel, server sends you a key + challenge encrypted with your password. You send back the challenge, encrypted with their key, that proves you knew the password. Then you use the challenge to encrypt the rest of the data. If anybody intercepts it, everything is encrypted and your password isn't even in the data so they can't reuse it later. The only chance to intercept this would be the very first time the user went to the bank site, when they entered their password.
That's the gist of how SSL works.
Of course, if you registered a new account on the hacker's site and used the same password then they would know how to decrypt the bank's messages, which is why a better way is for the bank to store a smart card / USB fob public key instead of a password. But a smart card or fob certainly isn't necessary to prevent mitm hacks.
Maybe he's writing in character? *queue fat man leaning at the top of a long staircase*
Quack, quack.
Fraud is so prevelent the banks have written it off as a cost of doing business. I had my account compromised a couple of months ago. I called the bank on the same day that I noticed the fraud and by the end of the day they had credited my account for the fraud, opened an investigation, and setup a new account for me. I didn't even need to redo any of my direct deposits, or automatic billing because it all transfered over to the new account. Wells Fargo calls it a "lost stolen transfer". I'm sure that other banks have similar catchy phrases for their own process.
In my case, I made the mistake of buying WoW gold from China. It always comes down to user education. If a person knows how to use a computer, they can make educated decisions and keep themselves safe. I live in Long Beach, CA and my city has a couple of classes a month about how to avoid online fraud. They are directed toward seniors and anyone else who is interested. I haven't been to one, but they probably just cover the basics. "Your financial institution will never contact you asking for your personal information." "Unless you initiate the transaction, it's probably suspect." "This is how you type https://.../ into the web browser."
If you are going to criticize someone's grammar. Your post should be grammatically flawless.
Because the commenter is a professional writer? Do you expect the same level of grammatic correctness from a journalist and a janitor?
He's speaking the language of the deal.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
That sounds like a good idea. There could be a DNS option on the domain for secure-only. Of course DNS has had its own issues, but every bit helps.
It is a bit late now but actually ensuring no password is sent in the clear (i.e. browser controls password entry via its own unfakable UI, specifically the one for HTTP auth, but clarifying whether it is unsecure basic auth vs. secure digest auth) would at least partially solve this problem as well. I would not want to use it for a bank, but getting users used to typing their passwords straight into HTML forms where they will (most likely) be transmitted in the clear was a bad idea.
As that is not really possible, smart cards are a good idea as long as they are carefully designed to actually be secure (ex. the RSA keyfobs that show numbers can just be MITM'd if the attacker can convince you to give your login details to them -- they just have to login immediately to use the information).
Also, if the card has direct contact with the computer, then any spyware running on the computer could use it to log into the user's bank while it is connected. This can be partially worked around by not allowing simultaneous logins (especially from the same unique smart card) (which banks probably already do, but I, naturally, have not tested) and notifying the user of their last login time (which my credit card company does).
It can start as a specially-formed TXT and transition to its own field, like SPF did. DNS spoofing is its own problem; if they own DNS they have you anyway.
I think he just invoked Muphry's Law
This is actually not a problem with SSL. It's a basic flaw in the design of X.509 (the certification spec that SSL uses), and has been known and talked about from the beginning. You have critical policy information (e.g., the "basic constraints" certificate extension) being expressed in a credential, but the consumer of that credential may or may not interpret the information correctly. The lesson here (which gives the lie to all the PKI hype) is that you cannot separate certification policy from application policy.
Yes.
...
it is?
me.
How,
did? you know.
I was being.
so damn care
ful.
about that...
Some credit card sites have this bug.
Log-in page loads over http:/// and then it submits to https:/// which is very vulnerable.
I hacker can change the login page (over http) to point to his own site. Before clicking submit you have to debug the page to find out if it is submitting to the correct site... and by that time it is too late. They can afterwards fake loading error and forward to original page...
And even worse, on some site I couldn't find a log-in form loaded over https.
Please note, that no fishing is required to do this - it can be done over live traffic. The attacker modifies the login page on the fly because it is loaded over http.
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.
Mobile phone companies are looking to do exactly this to HTTPS traffic transiting the GPRS network:
http://blog.masabi.com/2009/01/how-do-transcoders-affect-https.html
It won't be long before ISPs that provide dial-up connections do the same with their "web accelerator" products.
Oh, and Opera Mini does this as a matter of course.
A lot of business class notebooks have smartcard readers.
Every time you post an article on Slashdot, I kill a server. Think of the servers!
business class != general use;
call me when you have to actively avoid getting one without a smartcard reader.
I know tobacco is bad for you, so I smoke weed with crack.