Leetness Not Actually Required For Pwnage
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.
Dan Kaminsky's Blog 
OK, I didn’t finish reading yet, but I hit “nobody noticed there was no security” and went “huh? how do you not notice the green bar turned blue? or went away?” Then again, I guess that assumes Firefox users. Still…none of the 200 people tested were hackers either? I would *hope* people in the community would notice. That’d be interesting though…
Mackenzie,
Relatively few sites have EV certs. Nobody is noticing when “Domain Validated” SSL is missing. The open question, unanswered by Moxie’s experiments, is whether anyone would miss EV missing either. It’s an open question, really.
I just posted a “hey go read Dan’s blog” thing on my blog, and a friend pinged me on IRC. He has good questions. How much validation is required for EV? Wouldn’t it be possible for someone to legally register a business named Paypa1? Does Verisign just get a letter saying “yeah, uh, these guys are legit” from a lawyer, or is there human interaction involved? Basically, how can you game the system?
By the way, just double-checked to see if pnc.com is blue or green, and it’s blue so 😦 Will have to complain.
Mackenzie–
EV validation is pretty hardcore. Specifically, it requires a lawyer — a Verisign trusted lawyer — in the claimed jurisdiction to approve of the name. No validation process is perfect but EV is more of a business deal than anything else.
That being said, revocation in SSL is pretty weak, so if something did sneak through, we’d be pretty hosed.
I don’t think that the answer would be even in EV. People just DON’T NOTICE stuff… we’ve all seen it, you mentioned it here, again. I think that people must be provoked by beeps, big flashing signs and buttons that can’t be clicked for a couple of seconds so that the user can actually TURN some attention to what’s going on. Yeah, sounds silly, but I think that WOULD give results. Your opinion?
Dan, you’ve made a good point there. EV is not THE ANSWER/SOLUTION to all “problems” ‘exposed’ by Moxie. At least not in the current mixed environment.
As perverted as it may sound, and I kind of hate myself for suggesting it but only strict regulations and international laws could prevent stuff demonstrated by Moxie IMHO. On the other hand we really have enough of this SoX, HIPPA, YouNameIt comliance thingies and regulations for the price of our freedom/anonymity.
I guess that only a so called defacto standard or regulation (eg. EV only certs for all sites and services related to financial services) in combination with further technical meassurements (DNSSEC, WoT-esque techniques) could max out security in this case. And we all know how easy international regulations can be carried out… 😉
Obama, can I haz DNSSEC please?
My $0.02,
Jan
Just saw the thing on networkworld (and hey, more press is always better, huh?) and thought I’d drop a little nasty rain on the parade.
There are numerous problems with dnssec and crypto in general. For one, what do you suppose Joe Average can and wants to do should our fancy crypto solutions say he’s looking at nasty evil stuff? Remember, it’s standing between him and his porn, and NOBODY stands between Joe Average and his porn.
But the nastiest thing by far isn’t how to make crypto transparant. It’s the same thing that DJB doesn’t get either: Policies and politics, in short the big scale version of the power games people like to fsck each other over with. In casu, I and with me many non-Americans but certainly at least some Americans also, could never agree to the American Government holding the keys to the naming infrastructure with hard crypto.
And that no promise or guarantee will be enough. Ever. The fact they already do except without the hard crypto is hard enough to stomach already, but can be ignored as long as they pretend they don’t. Crypto changes that.
You can like it or not, but that’s the situation. If that gets pushed through, expect multiple internets with disjoint naming trees in the long and not-so-long term. So please don’t go there.
This is not to say dnssec wouldn’t fix the problems you’re trying to protect against, but unless the dns root keys get distributed to some international, multinational, fluid, disjoint, not easily influencable by any single government or megacorp, and preferrably democratic, collective of keyholders or something to that tune, instead of the status quo, ie a zombie sockpuppet ICANN and the USGOV pulling the strings, mere pushing of dnssec as a technical solution will cause severe non-technical problems on an epic scale. This means going back to the drawing board and either come up with a technical solution without the side effects, or address the non-technical issues and to make that work, move mountains. Sad, but true.
By and large I don’t think EV will make a lick of difference, for at least a couple of reasons:
1) Inconsistency: Of a random sampling of financial institutions, few are using EV certs. (Wells Fargo, BofA, US Bank, to name a few; just by hitting https://www..com/ of course — I suppose their actual ‘login’ pages may be different)
2) Lack of awareness: Of the people I polled, few noticed the difference between the blue-background favicon of, say, Wells Fargo, vs. the green, emblazoned favicon of PayPal. Of those who did notice, they assumed it was a customizable UI element, ala the favicon.ico itself. (Note: These are technically competent people I’m referring to; my parents, for instance, would have fared yet worse).
It goes hand-in-hand, I suppose. For positive feedback to work, the end user has to have some expectation that fails to be met. With inconsistent deployment of EV certificates, that expectation has not been created — so a failure to meet it will go largely unnoticed. User education can help bridge that gap, but it still requires cognizance on behalf of the user that any given site *used to have* and *now does not* have the pretty green box associated with the EV cert; frankly, that’s an unreasonable expectation from all but the most security-minded of people, and even they are susceptible to outside stimulus that may momentarily distract them from the lack of EV validation — negating it’s effect entirely.
That said, of course, it’s a great start — and for places where it’s used, I’m happy to have it in place. 🙂 At the very least, it tells me that the vendor in question is on their game, which is definitely something to be aware of.
Oh, and as a case-in-point of how *not* to do things, check out Citibank.
Start with https://www.citi.com/
Then move on to (the particularly laughable) https://www.citibank.com/
Granted, you have to go to https://online.citibank.com/ before you can even think about giving them credentials, but it’s still a bit of a mess when you compare it to, say, Boeing Employee’s Credit Union at http://www.becu.org/.
Anyway, ’nuff of my ranting. 🙂
While it certainly doesn’t look like Moxie’s attack is the most technically complex, it does seem like what makes his attack unique is that he’s actually put all the pieces together, worked out the details, and *written a tool that actively does it* with very high success rates.
It’s not enough to simply suppress the 302 with a 200, for instance, because PayPal won’t accept future non-https requests from the confused client.
I’ve also seen some comments from him indicating that this “stripping” thing is just the most basic version of what’s possible, and that there are other things which become possible once you’re attacking the jump from HTTP to HTTPS — which he hasn’t yet disclosed. Looking at his website, I’m not sure that he ever will.
Decent amount of stuff to respond to. Lets go down the line.
John–
One weird problem you have is that if crypto is too distracting and ugly, sites won’t deploy it, because it’s too distracting and ugly. There’s been a progressive trend towards shrinking the amount of browser real estate more and more, because users aren’t using a browser to see a browser, they’re using a browser to see web pages. So positive feedback systems are having to do more and more with less and less. Moxie’s data suggests we need to rebalance things a little, but exactly how is an open and interesting question.
There’s some really annoying data, by the way, that suggests that if you warn people about security vulnerabilities, they will trust your site less — and should. A survey of sites that had security labeling on them actually showed them more insecure, not less, than the average site without. So it’s rough.
jweck–
I’m not really sure how regulations could or would work here. But obviously what we’re doing isn’t exactly working.
Holger–
1) Awareness is increasing. Moxie should help with that, actually. It’s fair to say however that years of complaints haven’t gotten all the banks to fix their login forms, just most of them. So you’re right that it’s a continuing struggle.
2) I actually prefer the IE approach, where the entire bar turns green, versus the FF approach where just a section does. This needs testing.
Serge–
I’m not going to speculate on what tricks Moxie does or doesn’t have. There’s a huge set of amusing things someone can do once security is stripped, but at the end of the day, his tricks come down to exactly what EV was intended to solve.
Whether EV actually works, I maintain, is the most interesting question to ask after Moxie’s talk. Where’s the data?
I think it would be good, in terms of the “remembering how it was v. how it is” thing, if when a bank deploys more security cues, they send out a snail mail letter to their customers (because hopefully people have learned not to trust email from banks) saying “We are now doing ____ to make it easier for you to tell if you’re really at our site or are being tricked by a phisher. Any time you visit our site, please look for $visual_cues to make sure you’re not being watched by a cracker. Also, please remember that we will never ask for your password in an email…blahblahblah” (though I suppose they’d probably say hacker, not cracker, but oh well).
That could at least help on the user-education front. Telling your parents, siblings, and friends what to look for could help too.
Dan says…
“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?”
Well, not exactly, but we do have a comparative study. Researchers took *existing* BoA customers (that have used internet banking and the site), and removed the sitekey element (supposed to stop phishing). 58 out of 60 people entered their passwords anyway. These are people who have used the site, and knew-of/saw the positive feedback, and ignored the lack of it anyway.
http://www.nytimes.com/2007/02/05/technology/05secure.html?_r=1
If this doesn’t answer your question I dont know what does 🙂
Dan,
I’m a founding member of the CA/Browser Forum (the EV SSL standards body) and a VeriSign executive, so you may imagine I’m deeply interested in the effect of green address bars for both personal and professional reasons. You should understand that the answer to your question isn’t binary. In other words, some people notice the green address bars while others miss it. The research indicates that the number of people who see green address bars is significant and that it’s a meaningful and useful addition to browser security.
The best study I’m aware of is the one we commissioned from usability research firm Tec-Ed in January 2007. Tec-Ed put 384 active online shoppers through simulated purchasing scenarios with and without green address bars to measure the green bar’s influence on behavior. One thing Tec-Ed found was that when subjects go a site where they expect to see a green address bar based on previous experience, if no bar is present that 70% of them indicate suspicion about this site.
I view that as a big positive. Certainly it’s not 100% of site visitors, but it’s quite a stride in the right direction. I have a longer posting on the Tec-Ed research here: https://blogs.verisign.com/ssl-blog/2008/06/so_how_does_ev_ssl_protect_aga.php#more
Ted, sorry to rain on your parade. First thing I thought when I heard about EV was “Cute, standard industry initiative, entirely the wrong thing. As usual.” This isn’t a condemnation of you; the problem is just much larger and harder than even the people who know about this sort of thing realize. Let me sum up some of the UI problems with crypto in general and applications in particular.
First, people don’t understand it. It isn’t that they don’t understand the algorithms involved, they really shouldn’t need to. But the world it plays in is alien to them. I’m going to leave the essay with the details as an excercise. Compare the ways a lock on your front door does and does not work like ssl in a browser. For starters just the usability side.
And then consider that we’ve told them “don’t worry about anything, it’s i n t u i t i v e”, when their moms and dads never claimed such a thing about keys. They had to be old enough to be trusted with the keys to the house. With keys, it’s widely known and understood what the risks and damage potentials are, at least well enough for Joe Average. By contrast, impact of compromise in the digital world is immediate and network-wide, and largely invisible.
Which explains why nobody cares about address bars, be they white, yellow, red, green, purple, infrared, or you name it what other shade. Nobody looks hard at that addressbar and if they do it’ll be dismissed as another software quirk. They’ve been conditioned to accept crap from software. Any software. A lost house key, OTOH….
Then there’s the problem of what to do when the browser says, wrongly or not, there’s something funny going on with the certificate. Many houses have two doors, and those that don’t, well, maybe you’ve given a key to the neighbour or you have to call the blacksmith. Oh well. But digitally?
Going from failure modes to non-failure modes: Who do you trust? Even when the cert isn’t known to be forgeable, we’re asking, nay forcing, people to trust faceless companies without credentials who proceed to make a tidy sum on the resulting trust scam.
To require more lawyers is just adding insult to injury. I can accept a PKI structure for, say, the government if it starts with a certificate signed by the head of state, for example, provided I can go to the local franchise (townhouse or so) and verify the certificate myself.
One could, on a national scale, legislate that to own a domain in bank.ccTLD you would have to have a banking licence issued by that country. But obviously that won’t work for a while to come on a planetary scale. The fact that .com et al. really have an implicit .us tacked on tends to confuse the issue. Worse is that it only works for small groups like banks, and will not work for anything grassroots, ever.
But so far even governments will be using corporate certs because, oh, that’s easy and cheap at the price, provided you don’t mind unaccountable trust roots.
To be fair, I don’t mind hard crypto and auth, provided we know exactly what we do with it and what we use it for, and, not a small thing, we don’t over-reach and use it for everything.
Most real-world trust is mutual, not hierarchical, but both mechanisms are used and necessairy. So we’d need a crypto system that reflects that. And to make it usable in the general case it must also always allow for mutual authentication, like kerberos does. This extends to identity for people, corps, states, and must include forms of weaker auth like for the nickname I’m using.
Without we’ll be killing free speech and a host of other things that we’ll suddenly find require the possibility of the authenticator not find out everything about our persona at once, or that we maintain multiple personae, quite legitimately.
So, again sorry to rain on your parade, but I really do fail to see EV as much more than what
CCV is to CCs, an inept patch on a broken system. To fix it, we need to understand the domain and come up with something that both is comprehensive and properly allows for situations that it cannot deal well with, after all.
@Tim…
I guess the crux is the word “indicate” in your comment above. Lots of users might guess at something not being quite right, but how many actually ignore those warnings (several in the BoA study I linked to above noticed thins “not quite right”, but continued anyway).
It’s just like the normal SSL warnings you get – I’ve asked many (non-security/computing) people what they mean and the response is mostly “blah, blah, blah, if I click this button I can get on with my work”.
This isn’t a failing with the tech, or the idea, but people. We can help them out as much as you like but there will be a (significant) percentage that will do the “wrong” thing.
Users’ ignorance and willingness to conduct transactions through unsecured links will continue until:
(1) browsers begin to require encryption by default, and start providing lots of tedious negative feedback before they’ll let you use a nonencrypted site;
(2) the likes of Google, and most other sites, realize that by not saving on not using SSL, they are contributing to the problem by preventing browsers from implementing #1, and training users to use unencrypted sites.
That poses a tough, possibly unworkable problem of coordinated action.
What can we do instead?
Putting DNSSEC aside (whenever _that_ will be ready), there could be a secure registry of sites which must be accessed via SSL. This registry would itself have to be accessed via SSL, and browsers would check it automatically. Browsers would then enforce either secure navigation to these sites, or provide strong negative feedback to discourage access.
Browsers accessing a central registry looks a heck of a lot like CRL’s — Certificate Revocation Lists. We see how well THOSE scale.
While I type this comment on what I hope is your site (http:) I did want to point out one error. “100% of Paypal can, and must, be retrieved over SSL.” Not true. The first request and response may be plaintext that’s what makes Paypal “vulnerable” to attack. You can train all users to use https only and complain to all sites that don’t use SSL, but good luck with that.
EV SSLs sound nice, but I’ve found in practice, having purchased several dozens, that my faith in them is nil.
I’d be curious how small a “company” someone can be (LLC, my own little company at home?) and still get their first EV SSL for http://www.soleproprietorsh!p.com or something.
And once you get the first one, as long as you own the domain (no checks there!), you can get an EV SSL for any of them after that. Over half of the ones I buy are ‘branded’ for sites I run under brands I don’t own at all. (Yes, they are customers, but no one is proving that.)
That all said, it will help EV SSL adoption a TON if the CAs can be more transparent with their practices and explain exactly what happens to validate an EV SSL and prove the value. And I’m not just talking studies on who cares about the green bar, but rather who asks what questions and what proofs are provided. Honestly, it’s going to come down to phone calls, a minor corporation records lookup, and some customer service rep pressing a button to Ok it. And that all only on the first one purchased. If they have a good process, it should not hurt to let us all know. But I don’t feel that love at all.
(In my observation, it is not the green bar people care about so much as getting away from a red bar…as long as it is not red, then green or white is just fine. But this is more of a browser problem than a CA problem…)
This may not be revelant but i figured i’d post this anyway. If you’re using ubuntu 8.10 you may be in for some issues with the network manager. For some unknown reason it stops functioning. You will need to manually set you’re resolv.conf with your ISP’s DNS servers. That file is located in /etc/network/resolv.conf