Why SSL needs certificate authorities, or at least trust roots

January 2, 2009

Despite what I wrote yesterday and my general views on authenticating SSL, I think that in real life SSL still needs certificate authorities, or at least some sort of trust roots. The problem is that normal people are simply not interested in assessing trust issues and probably are not capable of doing so. In fact I'm not sure that I'm capable of doing it.

(As I wrote once before, in practice I make no attempt to actually verify the SSH host keys that I get prompted to approve, so the odds that I would hand-validate SSL certificates is low. And I am far more technical and aware of these issues than ordinary people are. Remember, security is a pain.)

If SSL is going to mean anything more than very casual opportunistic encryption in practice, we need to delegate trust issues to someone; in other words, we need some sort of trust roots. The traditional alternative answer to this is a 'web of trust' model, but this is just a cop-out, and a dangerous one at that. You're still leaving it to people to pick their own trust roots, with the predictable result that many people are going to do a bad job of it. Plus, in practice I believe that the whole model has flaws that weaken its security.

(Yes, yes, at this point it is popular to blame the people for not doing their 'job' correctly. Wrong. If you design a system that you know is going to be used incorrectly by people, you have failed because you haven't solved the important problem.)

(On a side note, I'd expect a web of trust system to have even more problems with revocation than SSL currently does, since it would involve more signatures that are more widely distributed.)

This doesn't mean that you need certificate authorities as they currently are (that would be truly depressing), but it does mean that you need trust roots and networks of trust that are trustworthy enough that they can be configured into browsers and shipped off to people who don't want to care about all of this. My feeling is that each trust root will have to have a pretty flat trust hierarchy in order to stay trustworthy overall; we've already seen the practical problem with doing otherwise.

I haven't thought very much about how many trust roots there should be. On the one hand, more trust roots should mean that less depends on any given trust root, which would make it easier (in practice) to revoke one when things go wrong. On the other hand, the more trust roots you have the less you can inspect and monitor each individual one's operations, so they can be sloppier before getting caught.

(The cynic would say that there is no real monitoring of CAs now; all you have to do is pass an initial inspection and then you're pretty much set.)

Written on 02 January 2009.
« Flaws in the 'web of trust' approach to trust issues
How to help programmers (parts 2 and 3): os.environ and sys.argv »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jan 2 01:14:13 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.