Slashdot Mirror
SSLStrip Now In the Wild
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."
I guess the question then is, what do we use as an alternative? What can we even do?
Bored at work? Play Game!
You could also try to read about it... The problem is not with SSL, it's with an attacker redirecting the traffic before it is in SSL, as your typical banking session usually start in plain HTTP. People then fail to understand the visual clues given by their browser. This attack is a nice technical MITM/social engineering mix, countermeasures are not really purely technical, if banks stopped to be cheap and did all their serving over HTTPS there would not be any HTTP traffic to modify in the first place...
Reading TFA, it seems to me that there IS something that the end user can do to protect themselves: Look for the https:/// in the address bar and DON'T LOOK THERE (favicon.ico area) FOR THE PADLOCK... the padlock should be down in the statusbar area where it always is.
Out of reflex, I always check that my URL starts with https:/// and I check the cert when I'm dealing with someplace new. Now, I'm just always going to check the cert... even if I'm connecting to a site I use all the time.
If Moxie really wanted to make things tougher, they could maybe add a cert to their tool. THAT would make it so you'd only notice if you read the cert and realized it wasn't what it was supposed to be.
THAT's scary.
The Digital Sorceress
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.
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.
SSL is NOT broken. It is still an effective way to encrypt network traffic.
.com hostname should be ASCII while a TLD for China should be IDN.
Knowing that, get a hostname in a CC TLD. Get a certificate for your hostname. Then create a really long hostname using IDN so that the TLD portion will be pushed off the end of the address bar. You can forge any legitimate web site this way and the only indicator is either examining the certificate or looking at the TLD in the URL. There are IDN that look like slashes, so making a "path" is easy.
The attack breaks down two ways. Proxying web traffic between a user and a sensitive site like a bank and/or repsenting a URL to a user that looks legitimate but isn't.
The indicators that you are on an SSL site are varied. A lock in the lower right of the window (FF3), to the right of an address bar (IE 6 and below), or a green address bar (IE7 EV cert) or a green indicator to the left of the address bar (FF3). All except the EV SSL certs are pretty subtle. The success relies on the fact that there are so many varied ways that SSL protection is presented to the user, can you keep track of it all. Quick, which sites use EV certs? You don't know so you don't know what to expect.
So, the attack does a couple of things to fool you. First it proxies your web traffic to secure sites re-writing urls that start with HTTPS to HTTP. The only indicator in browsers is no lock. If you are not looking for it, then you probably won't miss it. But wait, since we are rewriting URL's, why not replace the favicon with a lock. Yummy.
The second type of attack is to proxy HTTPS to HTTPS, but this time the SSL session between you and the proxy is enabled with a valid and trusted SSL certificate. No SSL dialog boxes. Here is how it works. IDN is used so that countries can represent URL in their native character sets. Some non-ascii characters look like characters. So use them to fool the user. These are called homographs. Browsers will convert some IDN based on the TLD. But other TLD, like country codes TLD, the browser won't. The assumption being a
Moxies video is pretty clear.