SSLStrip Now In the Wild 208
An anonymous reader writes "Moxie Marlinspike, who last week presented his controversial SSL stripping attacks at Black Hat Federal, appears to have released his much-anticipated demonstration tool for performing MITM attacks against would-be SSL connections. This vulnerability has been met with everything from calls for more widespread EV certificate deployment to an even more fervent push for DNSSEC."
Re:Sounds ugly (Score:5, Insightful)
Security is a social issue. Educate! (Score:5, Insightful)
This attack does not break SSL in any way. It simply tricks users into entering sensitive information into unencrypted context.
The solution is user education. We need to train users to look for the browser padlock icon. We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user. We need to train users to click "no" on security dialogs when they appear. We need to tell users that a padlock icon a website puts next to a form is unacceptable. We need to train users to be vigilant, because nasty people are trying to steal their information.
I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings. I'd like to see public service advertisements. I'd like to see basic computer safety classes in public schools. User education is the only hope we have against stupid users!
The fault lies partly with browsers too. Firefox, particularly, should never have toned-down the non-EV SSL user-interface --- sure, making EV special is fine, but allowing sites to spoof the SSL UI with a favicon is unacceptable. People have been saying this ever since Firefox 3 came out, but maybe now someone will pay attention to us.
Huge pet peeve (Score:5, Insightful)
A site should never lead the user to type sensitive information into a form on an unencrypted page, even if the form's data goes to an encrypted location when submitted. Doing this trains users to be lazy. What's even worse is trying to alleviate users very correct fears by putting a padlock icon next to the form. That's even worse: doing that trains users to believe that a website can signal its own trustworthiness apart from the browser UI, and that could have disastrous consequences.
I have a technical solution, but it won't be popular: browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL. Since web designers are afraid warnings will spook users, they'll switch to making the form-entry pages encrypted as well.
Re:Huge pet peeve (Score:5, Insightful)
IE's warning appeared on all form submissions. I agree that warning was worse than useless.
I'm talking about warning only when the following conditions apply:
The user should not be able to disable the warning; its existence will lead webmasters to change condition 1.
Re:EV certificates (Score:3, Insightful)
Like most human behavior, this problem can be explained by economics.
The problem is that the CA system creates the wrong incentives. You, as a CA, want to sell as many certificates as possible. There are almost no repercussions for issuing a fraudulent CA. In theory, browsers are supposed to remove rogue CAs from their CA lists, but in practice that doesn't happen: they're too afraid of "breaking the web" and being sued to actually punish CAs for having lax security.
Comodo, for example, delegates its CA business to fly-by-night subsidiaries who issue certificates with no verification whatsoever. This is the worst situation imaginable from a security perspective, but even after this contemptible practice was exposed, neither Microsoft nor Mozilla Corp. removed the Comodo root certificate. I've personally removed it in all the browsers I use, but most users won't do that.
Comodo's behavior is no surprise, however. For them, it makes sense from an economic point of view. Yelling and screaming will change nothing. The EV program is slightly better in that it's an industry agreement to perform better validation, but it'll inevitably succumb to the same market forces. As EV certificates become more entrenched, it'll become too difficult to punish rogue EV vendors, and we'll be in exactly the same situation we are today with standard SSL certificates.
CAs validating websites and taking payment from them creates the same perverse incentives that led credit rating agencies to contribute to the current economic crisis. You can't count on people's goodwill to make them do the right thing: if you want the right thing to happen, you need to make the right thing the easy or profitable thing.
There are a couple solutions to the incentive problem:
I wish I could come up with better ideas.
Re:Not the end of the world (Score:3, Insightful)
Another, perhaps more reliable option would be to change how long URLs are displayed.
Right now, if a domain name exceeds the length of the address bar, it's truncated on the right. Consider:
www.paypal.com/foo/bar/qux/sessionid/12341/do.myevildomain.com. If this URL is displayed as:
www.paypal.com/foo/bar/qux/sessionid/123
the user will be fooled. What if, instead, the truncated domain name looked like this?
www.paypal.com/foo/bar/...341/do.myevildomain.com
That way, no matter what evil junk is in the domain name, the user will see both its beginning and end and know something strange is going on.
Re:Alternatives (Score:3, Insightful)
Even this doesn't work. Legitimate banks do this (http://www.usbank.com is one, who I've banked with in some fashion since I had a net worth of over $50). Note that after you type your username in, you're taken to a secure page.
Re:Alternatives (Score:5, Insightful)
We don't need an alternative to SSL. We need browsers to implement proper UI. The user MUST be made aware if clicking a button would transmit a password in cleartext. The user MUST be made aware exactly which domain they are connected to during an SSL session. On a large busy screen, a tiny bit of text in a corner is the wrong way to do this.
Re:EV certificates (Score:3, Insightful)
There are a couple solutions to the incentive problem:
I wish I could come up with better ideas.
Having a CA funded by anyone but the website also doesn't work, since the site needs to get a certificate from the CA before going live. And unless it's ICANN running the CA, a site might need to get certs from multiple CAs if people in different countries or with different browsers want to talk to them.
Hmm, there's a thought. Self-signed certs, with the root cert fingerprint available as a DNS record, using DNSSEC. Then get the real-world identity info from 'whois'.
Or use something based on "can't fool all of the people all of the time" like Perspectives (see sig), where instead of having a CA that gives the site owner a certificate, there are a bunch of public servers that you ask whether they see the same key you see for whatever site you're going to.
Re:EV certificates (Score:3, Insightful)
I don't see why a site requesting a CA needs to be live. Consider FooCA, a for-pay CA that users subscribe to, or that ISPs subscribe to on behalf of their users. (There are other models --- this is just an example). If BarInc wants a certificate from FooCA, BarInc just applies to FooCA as soon as BarInc incorporates and obtains BarInc.com. Why would BarInc.com need to be live at this point?
That's a thought. But first we need DNSSEC, which would make me a happy man in any case. :-)
That solves some problems, but I'd rather have a robust CA system so that nobody has to be in that group of fooled people. Perspectives also adds significant latency to the connection and has other technical problems, but combined with other security measures, I don't see it as being all bad.