Why I want direct certificate checking instead of having to rely on CAs

January 18, 2007

The common SSL model is that you verify someone's good nature by checking to see that their certificate is signed by an approved CA. For example, if you are verifying that hosts you are connecting to are approved you would make up a CA certificate, then make up a bunch of host certificates and sign them with the CA certificate. When you connect to a machine, you verify that its certificate is signed by your CA certificate.

(Except that that's a simplification; you actually need to verify that the certificate is signed and that some identifying information in it is correct, such as the machine's hostname being the CN.)

The alternate approach is to directly check that each host's server certificate is in your list of approved certificates (and perhaps that it comes from the host that you expect it to). I maintain that this is the better approach for situations such as host verification.

The problem with the CA approach is dealing with bad certificates. First, you need to use not just a CA check but CA plus CRL, because if you just check for your CA signature the only thing you can do when a host certificate is compromised is to change to a new CA certificate, which invalidates all current host certificates. Unfortunately, CRLs are not widely used in the wild, so they are not necessarily well supported in tools.

Even with CA plus CRL you still have the risk that an attacker has managed to get some signed host certificates of his own (whether by quietly compromising your keys or by surreptitiously inserting things into your processing pipeline). Since you do not have copies of these certificates yourself (unless you catch one live during a host verification attempt), you cannot generate CRL entries for them; if you think this may have happened, your only recourse is to change your entire CA certificate.

By contrast, directly checking that you know each host's server certificate is much easier and more direct. You have a complete list of what certificates you accept and who you accept them from. If a certificate is not there, you know it will not be accepted; invalidating a bad certificate is as simple and precise as rm.

(Plus, you do not have to maintain and keep secure a CA signing setup.)

What this boils down to is that the CA approach is 'everything that is not explicitly forbidden is permitted' (if it is signed by your CA certificate it is allowed unless it is in your CRL), whereas direct certificate checking is 'everything that is not explicitly permitted is forbidden' (it is only accepted if it is in your list of good certificates). The latter is a much stronger security model, plus is easier to manage until you grow quite large.

Written on 18 January 2007.
« A grump about the socket module's SSL support
Link: Peter Gutmann on PKI »

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

Last modified: Thu Jan 18 23:44:19 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.