I do need to make a post about DNSSEC at some point in the near future. But for now, I’d like to deal with the more immediate issue: Moxie’s SSL break.

You’ll note that’s not in quotes. There’s a pretty decent temptation to say Moxie’s attacks don’t “count”. Some of this comes from the fact that at the end of the day, these are his three attacks:

First, that when a site attempts to upgrade from HTTP to HTTPS, he can suppress the upgrade — possibly throwing in a “Lock” favicon which might trick the user.

Second, that there are a surprising number of online banks that still place a HTTPS form on an HTTP page, which can of course be downgraded (or as I pointed out, sniffed via injected Javascript).

Finally, Firefox‘s (not IE’s) defenses against Eric Johannsen’s IDN vulnerability could be bypassed by registering a domain and acquiring a wildcard cert in .cn.

The first two attacks have been discussed fairly extensively, while the third works in only one of the browsers. So there’s some grumbling. Lets talk about that.

When I gave my DNS Cache Poisoning talk last year, I devoted quite a few slides to the failings of SSL. To put it simply, there’s a reason I didn’t consider SSL a sufficient defense for DNS Cache Poisoning. Indeed, the fact that the 302 Redirect could be replaced with a 200 OK — replacing https://www.paypal.com with http://www.paypal.com — is right there on the first slide. (His favicon trick is neat though.) And a few slides later, I ended up quoting my 2006 talk with respect to online banks and their tragic use of weak security forms, replete with cutesy “lock” icons. Obviously I didn’t discover either of these attacks; they, and the rest of the litany of weaknesses described in my 2008 deck, have long been the sort of failings in SSL that we’ve all known are pretty deeply problematic.

But, at least the way I look at it, Moxie’s talk wasn’t about some “l33t new protocol flaw” in SSL. He’s traveled that ground — in 2002, his finding that a certificate for http://www.badguy.com could sign another certificate for http://www.bank.com via the non-enforcement of Basic Constraints is about as “l33t” as it gets. That’s been fixed for years though. This was instead a fairly searing critique about Security UI. Moxie introduced (to me anyway) the concept of Positive vs. Negative Feedback. Negative Feedback systems occur when the browser detects an out-and-out failure in the cryptography, and posits an error to the user. In response to the New Zealand bank data, in which 199 of 200 users ignored a negative prompt, browsers have been getting crazier and crazier about forcing users to jump through hoops in order to bypass a certificate error. The new negative errors are at the point where it is in fact easier to “balk” — to stop a web transaction, and move onto something else.

So Moxie’s putting his energy on the old positive feedback attacks — simply disabling the security, and seeing if anyone notices. And here he shows up with some pretty astonishing data: Nobody noticed. To be specific, absolutely 0% of users presented with missing encryption on important web sites, being asked to provide sensitive financial data to those websites, refused on the basis of missing security.

Wow. 0%. Seriously.

Why don’t users “get it”?

The most heartbreaking thing I think from Moxie’s entire deck is where he shows off what his attack does to Paypal, on an older browser. Paypal, more than most sites, has some paranoid, whip-smart engineers who really want to ship the most secure web experience possible for their service. As such, they have what’s probably the single most widely deployed SSL-only site. 100% of Paypal can, and must, be retrieved over SSL.

Unless there’s a bad guy in the way, faking the real Paypal content over HTTP. Then Paypal looks just like your bank.

That the insecurity of other sites would train users to not expect security on yours, was pretty cool (if sad) to see.

Where I do think things went a little off the tracks was when Moxie talked about his (pretty elegant) extension of Eric Johannsen’s IDN attacks. IDNs, or Internationalized Domain Names, exist to allow other languages the ability to have web sites in their native character sites, rather than shunting everything into ASCII. What Eric did in 2005 was show that he could acquire a certificate for http://www.paypal.com — with the a being the Cyrillic a — and thus acquire the “lock”, apparently linked to a near-pixel-perfect rendering of Paypal’s address bar. These so-called “Homograph” attacks were dealt with by locking down the rendering of other character sets in the address bar.

The problem — and it’s worth exploring, because it reflects just how tricky it is to satisfy all those other demands besides security — is that the trivial way to lock down the address bar, to simply ban Chinese and Cyrillic and everything else — has some pretty serious geopolitical implications. What, America gets to have its domain names, and China doesn’t? What’s up with that? Different browsers have dealt with this problem in different ways. I believe the way IE has handled this is to ask the operating system what language the OS is in, and allow Chinese browsers to view Chinese characters, Russian browsers to view Cyrillic characters, and so on. It appears Firefox handled this instead by saying that domains in *.cn may contain Chinese characters, domains in *.ru may contain Cyrillic characters, and so on.

But nothing stops Moxie, an American, from registering a *.cn domain, acquiring a *.ijjk.cn certificate, and using the Chinese character that looks exactly like a slash to make a fake http://www.bankofwhatever.com/foo/bar/foo.ijjk.cn domain. It’s a cute trick.

It’s also precisely what EV certificates exist to solve.

There’s an amazing amount of confusion around Extended Validation — EV. I can’t claim innocence here; I myself was pretty clueless about why they exist until fairly recently. Here’s the deal: Forget crazy tricks with chinese characters — bad guys have been registering names along the lines of http://www.bank-of-whatever.com or http://www.bankofwhateverinc.com or http://www.bankofamerica.com.xyzy.com for years, and then acquiring certificates for those names. Moxie’s attack is neat, but once you hit the semantic space, there’s practically an unlimited number of potential namespace collisions. EV exists, pretty much exclusively, to deal with the problem of these semantic collisions. It does four things:

1) It requires a solid certificate chain, as opposed to one containing MD5.

2) It requires a human lawyer, versed in the laws and language of a particular jurisdiction, to determine the implied corporate relationship from the domain name and declare it valid.

3) It applies a green background to the entire address bar (IE) or the leftmost side (Firefox), increasing the amount of “positive feedback” (as Moxie puts it) the user is hoped to demand

4) It explicitly inserts the human-lawyer-approved brand identity to the address bar, replete with a jurisdictional declaration. This also is there to add more positive feedback.

That’s what EV is for. It’s not at all there to deal with domain validated certs for http://www.bankofwhatever.com being incorrectly issued — see Adam Barth and Collin Jackson’s work in their paper, “Beware of Finer Grained Origins”. It’s not at all, as Moxie said in his talk, “Just the validation that CA’s should have been doing already”. Verisign et al have built an extensive, new positive feedback layer to deal with real world phishing attacks that, while not as elegant as Moxie’s Chinese Slash, were no less effective.

The real question, in the wake of Moxie’s work, is do we have data that shows users notice the missing green bar, and the missing brand identity? Or, even with EV sites, do users still ignore the missing security markings? I’m looking forward to seeing the data.