Wandering Thoughts archives

2008-10-05

SSL certificate revocation doesn't work (for web browsers)

How SSL certificate revocation is supposed to work is conceptually simple. The CA publishes a CRL, and SSL-using programs check the CA's CRL before actually accepting a signed SSL certificate. Despite this, SSL certificate revocation doesn't work on the web in either practice or in theory.

It doesn't work in practice because, well, it doesn't; you cannot revoke a SSL certificate today and have most web users notice. The only web browser that actively supports any sort of CRL checking is Firefox 3, and there is no clear sign that the CAs are actually providing revocation information to the certificate checking system that Firefox uses. Other browsers either have no support or have support but default to turning it off.

(Technically I believe that some browsers, especially IE, may ship with small static lists of revoked certificates. This is not meaningful certificate revocation.)

It doesn't work in theory because of those two vague words in the description: 'publish' and 'check'. This has two dimensions, the technical and the political. On a technical level, creating a viable system to do this is a challenging problem, because it must publish a significant volume of information, be queried at very high volume, and not impose significant bandwidth requirements on anyone or significantly slow down or impede https browsing (including when things go wrong), and all this while not leaking various sorts of private information.

On a political level, it is not obvious what CAs get out of actively and enthusiastically participating in certificate revocation checks. Certainly there doesn't seem to be any money in it for them, which leaves their economic interests misaligned with the goals of the whole thing.

(I'd say that the interests of the browser vendors aren't very aligned to this either, but browser vendors have a long and sordid history of being perfectly willing to make the user experience worse in the name of nominal and mathematical security.)

Sidebar: the pragmatic problem

All of this leaves unmentioned another problem: above all, any actively implemented certificate revocation checking must not misfire very often. In fact, it must almost never misfire. If it incorrectly identifies perfectly good sites as bad or otherwise blocks users from doing what they want with real sites more often than once in a blue moon, all that it will really accomplish is training users to ignore it or turn it off.

This is a significant risk given that a certificate's revocation status is currently unimportant information. There is a huge potential for all sorts of administrative mistakes to happen, causing perfectly good websites to fail.

(This is especially the case because in current usage, CRLs are supposed to list not just explicitly revoked certificates but ones that are obsolete for various reasons.)

web/CertRevocationProblems written at 01:07:21; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.