The core security problem of SSL on the web is too much trust

July 10, 2014

Every so often I'm surprised by what people don't already know (although I really shouldn't be). Today's surprise, due to Tim Bray's Blow up the Cert Business, is that people don't understand the core security problem with SSL on the web. I generally operate in an environment where this is common shared information, something that everyone just knows, but this is not the world in general.

So let's be explicit about what the real problem is:

The core security problem with SSL on the web is that your browser trusts a lot of Certificate Authorities and gives them power over any and all domains.

Your browser or operating system has a large list of built in CAs. Almost all of the time, SSL certificates signed by any of these authorities will be trusted to establish that you are talking to any random and arbitrary domain. There is no restriction on what domain names any of these CAs can issue valid certificates for and no mechanism that allows a domain to publish something that says 'no, no, wait, only trust SSL certificates for me that are signed by CA <X>'.

(Google has added special magic to Chrome to hard-code this for some domains, especially Google's. This has been extremely useful for turning up imposter SSL certificates, but it doesn't scale at all and thus it doesn't protect your site or my site.)

This means that the (global) security of your domain is hostage to the worst CAs and the CAs that are most subject to government coercion, because any of those CAs can issue certificates that web browsers will accept as valid for your domain. This is real SSL security (as opposed to the theoretical model with perfect CAs) and fundamentally why SSL certificates are a commodity. As the core weakness of SSL it has caused almost all of the SSL certificate security failures; some random CA that should not have any power to say 'I certify that this is website X' for some important X has in fact issued a certificate that says exactly that.

(The CA involved this time around simply makes it that much more obvious than usual, because it was not a general CA.)

This core problem of SSL cannot be fixed by getting better run CAs (or by imposing liability on CAs, never mind the problems with that). Extremely well run CAs are still vulnerable to government coercion and legal orders (orders that may come complete with gag requirements that prevent the CA from speaking out; we have seen that sort of thing in any number of places). For that matter, some CAs are themselves agencies of various governments (and your browser trusts them all and doesn't restrict what they can issue certificates for).

This problem cannot be solved by putting some or many commercial CAs out of business, as Tim Bray proposes. For a start you won't have gotten rid of the CAs that are effectively arms of their government. Beyond that, a root certificate that browsers trust is an extremely useful and valuable asset (perhaps a CA's most important one), one that will be transferred from owner to owner for as long as possible. I'm sure that there are any number of entities who would be happy to operate a CA at a loss merely to have power over such a certificate.

(Also, available evidence says that you can apparently operate a profitable CA that gives away free certificates. This suggests that putting commercial CAs out of business is going to be harder than you might expect.)

As far as I can tell the only way to solve this problem for real is for people to be able to somehow restrict which CAs can issue certificates for their web sites; an extreme version of this is for people to be able to restrict which actual certificates are accepted for their websites. Until this happens we will all remain hostage to all of those CAs that our browsers trust.

(I've written about these issues before, but I don't think I've previously laid out the core problem in black and white like this.)

PS: I hope it's obvious how much of a politically explosive non-starter it would be to try to drop perfectly operable CAs (either commercial or governmental) from browsers. As always, proposing something that cannot be done is not solving the real problem.

Written on 10 July 2014.
« What the differences are between Python bools and ints
Some notes on bisecting a modified Firefox source base with Mercurial »

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

Last modified: Thu Jul 10 01:08:59 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.