Insecure Eye Sockets Layer: Defeating SSL

Moxie Marlinspike's presentation New Tricks for Defeating SSL in Practice should be an eye-opening presentation on the fragility of the trust we place secure Web sites. Marlinspike uses some fairly mundane technical tricks coupled with astute observations about human behavior to pull off a difficult task -- seamlessly subverting the indicators of HTTPS Web sites presented to a user and fooling the victim into trusting when they shouldn't.First off, SSL isn't broken and Marlinspike doesn't say that, either. What is broken is how users perceive a secure Web session from an insecure one. Marlinspike pulls off this trickery pretty easily by proxying SSL connections, re-writing HTTPS URLs to HTTP URLs, capturing data in between, and presenting to the user a seamless and secure-looking Web session. SSLstrip will be available on Marlinspike's Web site thoughtcrime.com later this week. It's a technical implementation of social engineering, an observation Tom Claburn made in Black Hat: Security Pro Shows How To Bypass SSL.

I teach a graduate class on network security at Syracuse University. A few weeks ago we were talking secure e-mail and whether you should sign the plaintext first and then encrypt the message or encrypt the plaintext and then sign the encrypted message. I posed the question in terms of what it means to sign something. If you sign the plain text, you are asserting knowledge of the message. If you sign the encrypted message, you don't know what you are signing -- it's encrypted. Truth is, in either case, you don't really know what you are signing because the program does the work on your behalf and you don't see it. The program could insert anything into the message that you have just signed. I'm not going to get esoteric on you. My point is that we trust our programs are working properly based on visual cues from the programs. That's reasonable.

Go to your bank's Web site. Chances are that the url is of the form http://www.yourbank.com. If you try SSL, you can enter https://www.yourbank.com and you will have an SSL-enabled session. But look at the two different sites. Do you see any difference? If your bank isn't using an Extended Validation Certificate, chances are that the only indicators are a lock somewhere on your browser and the 's' in https. But the site looks the same. Marlinspike makes an amusing display during his presentation that there is little to indicate when you are using an HTTP versus HTTPS session. He even went to the trouble to create a favicon shaped like a lock -- a favicon is that little logo-looking thing you see next to the URL in the address bar. I think if I were to see a lock next to an http URL, I'd be confused and have to go figure out what was going on.

Then just to wrap everything into a neat little package, he then goes on to present a twist to that scenario where using a wild card SSL certificate and internationalized domain names (IDN), an attacker can seamlessly, with no visual clues, proxy SSL connections unbeknownst to the user. Web site certificates are usually tied to a specific host name like www.example.com. A wild card certificate can be used for any host in the example.com domain. Internationalized domain names allow countries whose alphabet isn't ASCII based to use their own letter or symbols in domain names. However, many IDN characters render as or similar to ASCII. These homograph attacks, combined with wild card certificates, can hide what is really happening form the casual user.

It's pretty clever and works because the application seems to behave normally. In an e-mail, Marlinspike elaborated:

Extended Validation To The Rescue

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 indentify 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.

I don't know what the solution is. If I did, I'd be seeking venture capital and working on an elevator pitch. But I think there are four things that can help:

The sad truth is, none of these suggestions will be adopted. It's too disruptive and everyone from browser vendors to Web site owners are too afraid of rocking the boat. SSL failures should be treated as such, but instead users are allowed to by-pass them easily, which is reinforced by years of clicking through error dialogs. Many years ago I advocated that financial institutions shouldn't send e-mails with links in them because that reinforces insecure behavior -- if it looks like my bank e-mail, it must be -- which enables phishing. But I still get them in my in-box.

Users are smart. Users want to know when they are protected and when they aren't. But inconsistent UIs and Web applications aren't the answer.