IMO, you've clarified well how SSL addresses the risks of eavesdropping versus MITM.

MITM may be a low risk; however, in order for self-signed certificates to become widely used, their use needs to be made easy and clear for users who have no idea what a certificate is. Of course, this is a big challenge.

Perhaps this wouldn't be such a big problem if, during the SSL handshake, an unknown_ca error were not fatal. Correct me if I'm wrong in how I understand this: If the connection remained open for this error, the host would be able to guide the user (via good web design) through the process of installing the certificate. This process could work something like, "Welcome, this is your first time here, in order to use our site you need to install the certificate or accept it for this session." This could be made better with some thought.

Short of that functionality (under the current model), the user is going to be presented with a warning that is too intimidating for many average users to accept.

Thanks!

Yes, Will, you've hit on precisely the thing. Self signed certificates are given short shift by the browsers - this derives from the old flawed security assumption that they are bad.

How the self-signed certificate is presented I believe to be a browser GUI issue and I'm not that fussed as there is competition warming up between Mozilla and IE, as well as others.

But here's my suggestion: it should be presented in the branding box - which would normally present a colour logo of the CA in glorious cached credibility. Instead of our well-branded CA logos, browser would present something like black & white with "self-signed" words in basic boring type.

In this, the user's intro to the security protocol is enhanced, something we know has to be done to address phishing. Now the user can see the self-signed one as boring, and the CA one as comforting. Not only is the security model enhanced, the CAs preserve their franchise by having enhanced incentives.

Basically, displaying the certs & CAs in a branding box (Amir Herzberg calls this a local trusted area, or LCA) is a win for all parties.

(Detail - yes, the popups have to go. They destroy the security by what I call click-thru-syndrome. Also, I don't think this is an SSL issue. It's up to the application to decide what quality of cert to accept.)

> But here's my suggestion: it should be presented in the branding box - which would normally present a colour logo of the CA in glorious cached credibility. Instead of our well-branded CA logos, browser would present something like black & white with "self-signed" words in basic boring type.

I understand now how you want to use branding for certs. This makes perfect sense to me, and it reminds me of how the founding of the UL dramatically improved safety for consumers. That is, consumers didn't need to know a thing about the mystery subject of electricity, all they needed to know was how to look for the UL label. Labels can be a simple, yet powerful tool for end users -- just thinking about labels causes the "look for the union label" tune to start in my head.

> In this, the user's intro to the security protocol is enhanced, something we know has to be done to address phishing. Now the user can see the self-signed one as boring, and the CA one as comforting. Not only is the security model enhanced, the CAs preserve their franchise by having enhanced incentives.

True. In the current context, the end user has no idea who are what Verisign is, nor do they need to.

>(Detail - yes, the popups have to go. They destroy the security by what I call click-thru-syndrome. Also, I don't think this is an SSL issue. It's up to the application to decide what quality of cert to accept.)

So, I'm guessing that if you were to design a browser, its settings would default to "always accept a self-signed certificate on first connection." For self-signed connections, the browser would display the boring "self-signed" words in the application gutter or on the toolbar.

there are two separate threats ... one carried over from the real world ... and one ... somewhat unique to the internet.

in the real world ... people that are dealing with unknown entities, don't really care who they are ... they care whether they can be trusted. this is the better business bureau model. certificates for this purpose didn't really fly on the internet because almost all transactions are done with known entities ... repeat business and/or extremely well known operations. They didn't need a certificate attested to whether they could be trusted. The other five percent of the transactions are spread over millions of commercial websites ... and it was/is difficult to drum up a revenue model that would cover reputation certificates. ebay is somewhat addressing this with reputation scoring.

the other issue is that you are dealing with somebody you know .... but because the communication is thru a untrusted and possibly hostile network ... can you really be sure that it hasn't been subverted. PGP has a model that covers this .... you acquire the public key and validate with some out-of-band process. This handles all of the entities that you frequently deal with &/or know.

This is effectively what has been for some number of commercial entities called certification authorities which have had their public key preloaded in browsers (before they are shipped) .... it is the PGP model ... but the out-of-band mechanism is having the public keys preloaded by the browser manufacture.

For commercial entities .... a PGP browser could be preloaded with a better business bureau public key. The better business bureau could maintain a table of registerd & trusted commercial entities ... along with their public keys and URLs. You can perodically download the latest table from the better business burear website.

So one question ... is it easier for the general public to understand ... if instead of describing the paradigm with analogies to the certificate model .... is it easier to describe it as a PGP model where the person loads other entities public keys (i.e. their signature verification mechanism) and uses out-of-band process to guarentee that they have the correct signature verification mechanism.

It might be easier for the general public to relate to a signature and a signature verification methodology. That is much closer to what they currently expierence. Trying to get the general public to relate to a certificate description paradigm .... (including self-signed certificate description) that has a couple layers of (unecessary) indirection ... would seem to be a much harder task

Hey, Lynn!

we can slice and dice models until they do the things we want, but we have to be careful to keep them close to some sort of reality.

In the real world, people make trust decisions through a network of sources. The BBB model is but one input. When approaching a store, chances are it is already known, there is a history, a trail of good transactions, and a pile of anecdotes to support any trust decision.

It's relatively rare that people enter places they haven't already trusted. Even when in a very strange place, people search for the brands they know. In fact, entering a place without any reference to a prior relationship is a very unusual event. When was the last time you did this?

It is this property that some of the better ideas attempt to exploit: Amir's logo stuff, my branding box, cert counts, the various URL redesign proposals (YURLs, etc).

In contrast, the existing web PKI has an *explicit* assumption that there is no prior relationship. So it tries to take on the whole burden of trust decisions on one metric and one metric alone - the tenuous ring of merchant/CA/browser/consumer as laid out in the chain of signatures.

It's no surprise that this can't be used for trust decisions, and it's no surprise that users easily (and IMO reasonably) ignore it for trust decisions.

The same can be said for PGP. It's not that the model can or can't be explained, it's that users - humans - don't do trust solely in that way. PGP works better because it lets in more relationships in its web of trust, but it is still only part of any model. For the most part, users don't trust the PGP web of trust even though they say they do. What they trust is the combined sum of all the little checks they do, of which, the PGP parts are some subset.

(Still, having said all that, the browser PKI infrastructure is in place, so it does give us a layer over which to place relationship information. The PKI layer is relatively strong, it's just mostly meaningless. The question is whether we can use it to add in enough meaning - at the browser level. It remains an open question.)

If people only went to sites/businesses they already trusted they could actually never build a group of businesses that they trusted in the first place. When new services arise the public is forced to be introduced to new and unfamiliar names, and eventually they acquire trust with the brand. Several factors come into play such as "trusted brand" failure (IE is a good example of people increasing their trust in Mozilla) Martha Stewart as well... some brands give you an excuse to leave your comfort zone...

Long ago and far away we were asked to work with this small client/server startup that wanted to do payments on the server. In the year that we worked with them, they moved from menlo park to mountain view and changed their name from mosaic to netscape.
minor references:

http://www.garlic.com/~lynn/aadsm5.htm#asrn2

http://www.garlic.com/~lynn/aadsm5.htm#asrn3

out of this work came something called a payment gateway and electronic commerce. along the way we had to do various kinds of detailed due dilligence on some number of the major things called certification authorities.

While the certification authorities were doing all sorts of integrity things ... it basically came down to making sure that the domain name you typed into your browser in some way related to the domain name of the server you were talking to.

This is significantly different "trust" issue from merchants taking credit card payments. For a merchant to take credit card payments, a merchant/acquiring financial institution has to take financial liability for the merchant ... and typically every transaction passes thru some processs related to that merchant financial institution before it gets to the consumers' bank.

With respect to the earlier post on this topic, we actually spent quite a bit of effort on certificates that had more meaning than whether the domain names match ... and weren't able to come up with a viable business scenario.

In theory, there is a requirement for trust for entities that have never dealt before. BBB, gov. & non-gov. licensing agencies provide some of this in the physical world.

In fact, various BBB and licensing agencies have looked at providing online, realtime trust information (as opposed to offline stale, static certificate oriented solutions) ... aka moving the paper certificates (hung on some wall) paradigm into an online 1990s paradigm ... as opposed to the PKI model that wants to preserve the pre-1990 offline paradigm with simple substitution of electronic bits for the paper.

The issue of the paper certificates in the pre-1990, real world ... was that there really wasn't a practical way of doing a realtime check with the authoritative agency issuing the certificate (hanging on the wall). To some extent, the PKI model is emulating the pre-1990, offline real world paradigm ... but substituting electronic bits for paper. However, with the emerging 1990, online world .... it is now frequently possible to go agency web sites and check realtime status.

to some extent this is the ebay model ... maintaining realtime information/history about parties active on ebay.

The comment about repeat business vis-a-vis first time business was based on paying for a trust infrastructure with something like transaction charges.

However, it turns out that something like 90-95 percent of the transactions are repeat transactions and/or with small number of extremely well known operations.

That leaves millions of commerce sites and possibly five percent (or less) of the transactions that are most in need of a trust infrastructure. So each of these millions of commerce sites are each making a couple bucks a month off thier commerce sites ... and, as a result, for each of these commerce sites there isn't a very large value proposition for paying for a trust operation.

The issue isn't whether or not a trust infrastructure is required for such market segment ... but working out a value proposititon to cover the costs of a trust infrastructure.

> If people only went to sites/businesses
> they already trusted they could actually
> never build a group of businesses that
> they trusted in the first place. When
> new services arise the public is forced
> to be introduced to new and unfamiliar
> names, and eventually they acquire trust
> with the brand.

Scott, it's not really the case that there is never any relationship. When new businesses start, there is no forcing about it. Instead, every new business does the same thing: it uses its existing relationships to bootstrap to new customer relationships.

Consider restaraunts: on the week before opening, they get all the staff's family, friends, suppliers, and whoever else through. This creates buzz. Then on opening week they try and get all the restaraunt critics through. More buzz. Next weeks they start tramping the streets, doing leaflets, offers, prizes, two-for-ones, happy hours.

All this is about using existing relationship to build new relationship. Every net business does it the same way - they get all their people using the service, and then they send them out to find customers. They pay magazines to write about them. Word of mouth is by far and away the most important marketing tool, so they often pay their first customers to find more customers.

(This is all by way of saying that the PKI logic that "they can do trust coz there is no prior relationship" is spectacularly wrong in every detail.)

Kevin Mitnick once tried an MITM attack against Hewlett Packard. He sent an e-mail, purporting to be from HP, to a customer (or perhaps it was vice versa) and the e-mail contained a PGP public key, ostensibly belonging to the named counterparty, but actually controlled by Mitnick.

Hm. I don't remember if he invented the e-mail or if he somehow intercepted a legitimate e-mail. I suspect the former, so I guess this doesn't really count as a good MITM example. Ask Jon Callas if you want details -- he is my source for this story.

I think Dug Song's dsniff, or some such tool, had the facility to do MITM against ssh.

Ross Anderson's "Security Engineering" contained a fascinating anecdote called "MIG in the Middle". In the on-line errata, Prof. Anderson says that this story turned out to be untrue, but that his military sources assure him that equivalent MITM attacks *have* happened.

Regards,

Zooko

Ian, I've really appreciated your rants against worrying about MITM attacks. I've agreed, and I myself have fussed that we worry too much about them.

I think protecting against a MITM attack is like protecting against a car being hotwired. Yeah, it's a security threat, yeah, I'm sure it happens, but having as a basic goal of a car that it not be *possible* to be hotwired is just a bit over the top.

MITM attacks are in general hard to pull off, and it's easier to pull off something else, like an impersonation attack that is impossible to prevent and difficult to defend against. What Mitnick did to us at DEC and what the armies of phishers do is much easier than a full-blown MITM attack.

Jon