Moxie Marlinspike's New SSL Attack is Nothing New

Moxie Marlinspike presented on a "new" way of attacking SSL at the Black Hat security conference on Wednesday. His tool, called SSLstrip, exploits the interface between http and https sessions using techniques that have existed for years. How does it work and what is the solution?

Essentially, Marlinspike's SSLstrip does a man-in-the-middle attack on normal, insecure http traffic and replaces links to secure https pages with normal http. A user will then submit their login or credit card details on an insecure page and the attacker running SSLstrip can collect those details free and clear.

Don't users know to look for the lock icon to make sure the information they are submitting is safe? Yes and no. When a user has previously checked to make sure that the page is secure when they log in to Google, they will assume that it will always be the case and won't bother checking every time. Also, Marlinkspike's SSLstrip takes some knowledge of human behavior into account and provides fake assurances that mimic real SSL-secured sites. For example, it can easily replace the Favicon on the page with a lock icon. The site will still show http:// in the address bar and the lock icon will be in the wrong place, but it fools a lot of people. Alternatively, Marlinspike demonstrated how an attacker could use IDN (International Domain Name) vulnerabilities to get an SSL certificate that will trigger the normal SSL indicators and display the domain name with https (https://www.paypal.com).

How well does the attack work? Marlinspike claimed to have gathered details on 117 email accounts, seven PayPal logins and 16 credit card numbers, within a 24 hour period.

Is this SSL attack new?

First of all, this isn't really an attack on SSL. It is an attack on the framework that surrounds SSL. No encryption has been broken. No fake certificates have been created (unlike the recent MD5 fiasco and Marlinspike's previous SSLsniff). This is simply a man-in-the-middle that forces users' browers' to avoid SSL altogether.

Man-in-the-middle attacks have been around for years. Marlinspike even comments on this in his interview about the SSL attack. What is new is the combination of several vulnerabilities into a program, SSLstrip, that MarlinSpike will be releasing to the world.

This attack doesn't demonstrate a weakness in SSL. It displays a weakness in the indicators and feedback in web browers when a connection is secure. Dan Kaminsky, another security researcher who pointed out the massive DNS security hole, pointed this out clearly in his response to Marlinspike's presentation.

EV SSL Certificates

Many have pointed out that sites that use EV SSL Certificates are immune to this attack. This is because EV Certificates display a very clear positive feedback (the green address bar or its equivalent in other browsers) that cannot be duplicated by a man-in-the-middle attack.

But there is one problem. It only works if users know to look for the green address bar. Unfortunately, it appears that many do not yet look for it. Marlinspike was able to sniff 7 different Paypal accounts. Paypal's website uses an EV SSL certificate which normally would have displayed the green address bar but didn't for the people that Marlinspike sniffed. They continued anyway.

Information Week's Mike Fratto is doubtful that EV Certificates will solve the problem:

No, extended validation certificates are not the answer. Not really. EV certificates are supposed to engender more trust in a Web site because a bunch of certificate authorities agreed on a common set of steps to authenticate a domain owner prior to issuing a digital certificate. While I applaud the ability of the EV certificate authorities to agree to a common set of criteria to identify an entity prior to issuing an EV certificate, and the visual cues like the green address bar in IE7 and Firefox 3 are much more pronounced than a little golden lock off in a corner, the fact is the user still has to differentiate between SSL sites and non-SSL sites. It's just adding one more confusing visual cue to a whole string of confusing visual cues.

The whole mess is exacerbated by too many formats, too many displays, too much reliance on users to interpret visual indicators. Today you can see a green address bar, a green indicator, a white address bar, a red address bar, a red indicator, a lock, or no lock. Unless you know what those things mean and where they show up in the browser during normal operations, it's all confusing. Marlinspike's demonstration using a image of a lock as a favicon (the common indicator for an SSL site) to fool the user into thinking they are at a SSL-enabled site. But the lock is in the wrong place -- on the left of the address bar. The SSL lock in Firefox is in the status bar and in IE it is on the right of the address bar. But you have to know that.

What is the solution?

What can be done to fix this problem? There are many things that should happen:

Ubiquity of EV SSL Certificates needs to increase at the same time as recognition of them increases. If people don't know they are on a secure, EV protected site, then we have the same problem.
As Mike Fratto reccomends "there needs to be a consistent user interface that all browsers conform to that shows when SSL is enabled and when it isn't. Meaning all browsers put the SSL-enabled display in the same place and in the same fashion."
"Web site owners like financial institutions that today mix HTTP with HTTPS should stop using HTTP for their entire site and move to HTTPS. Even a redirect from HTTP to HTTPS is OK. PayPal does this. If you get to Paypal.com and it is not HTTPS, then you know you have a problem. But even PayPal isn't consistent. Many of its footer links are HTTP links and should be HTTPS."

Links

Moxie Marlinspike recently updated SSLStrip to take advantage of a null character vulnerability in browsers. See Hackers expose weakness in visiting trusted sites.

Originally posted on Sun Feb 22, 2009

Comments

j-o-h-n(2014-12-13)
Also the lame punycode kludge should be replaced with something which clearly calls out that you are going to a hostname with characters not in the charset of your locale.
Robert(2014-12-13)
Thanks, Steven. You're right that ssl strip can easily intercept a HTTP redirect. I think Mike was saying that if your whole site uses HTTPS, it will be obvious to users if they have been redirected to a normal HTTP connection. The problem is that many people are fooled and an attacker could use a certificate (albeit an invalid one) to trick others. So it is really only an improvement and not a complete solution to the problem.
Ana(2014-12-13)
This is a very fine and quite detailed technical response to MM's ssl attack, which as you point out is neither new nor truly an attack on ssl. And, of course, what's assumed to be the cause of the problem -- ev ssl certs not working -- is actually the best solution to the problem. As more sites adopt ev ssl (withOUT mixing them with dv certs et al that leave one's site open to iframe attacks) these problems will disappear. I'm not quite clear on Duane's post, although I'd be interested to hear a more thorough explanation. >>I disagree with the sentiment that EV certificates are the only way to address this issue, all sites everywhere should always use encryption. Isn't EV SSL a TYPE of encryption people should use? Also, widespread use of the same passwords is definitely a problem, but a separate one, I think.
Duane(2014-12-13)
I disagree with the sentiment that EV certificates are the only way to address this issue, all sites everywhere should always use encryption. The reason is simple, people re-use passwords, they may have only gotten 7 paypal passwords, but how many could they re-use from elsewhere in brute force attacks? Once enough 'dead' wood has been attacked the survival of the fitest will kick in and people will wise up eventually, or maybe that's just wishful thinking.
Steven R(2014-12-13)
The solutions say "Even a redirect from HTTP to HTTPS is OK" This is not the case, ssl strip will modify the Location header moving the users session from HTTP to HTTPS and replace HTTPS with HTTP. This means the user is never switched to the encrypted channel.