Certificate authorities seem to be a real weakness in SSL

December 31, 2008

My main reaction to recent events is that they show how certificate authorities are one of the real practical weaknesses in SSL. All of the theoretical security in the world can be trivially thrown away by shoddy practices on the part of a single trusted certificate authority, and we've recently seen not one but two such CAs exposed.

The case of the improperly issued mozilla.com certificate is a clear-cut procedural failure, either failing to vet your resellers or failing to properly vet a signing request or, for that matter, both flaws at once, depending on your perspective. My view is that it is both at once, since Comodo appears to have been happy to take money from what could generously be called an extremely dodgy reseller and to delegate customer verification to resellers, which I am not convinced is at all consistent with a CA's responsibilities.

While the RapidSSL CA exploit is primarily an attack based on the weaknesses of MD5, note that it was only made possible by the sloppy security habits of RapidSSL, namely sequential serial numbers and fast, predictable signing speeds. The latter is especially significant as a CA security issue, because it means that the ability to sign certificates with RapidSSL's CA certificate is very 'close' to the public-facing website and is fully accessible by automated means. Even if an attacker who can compromise the website does not get the CA private key, they have probably gained the ability to get a valid certificate for any host.

(I am going to generously assume that RapidSSL's internal software won't auto-sign CA delegation certificates or wildcarded certificates, and that RapidSSL's private key is held in a hardened dedicated crypto processor, not in something that an attacker could compromise.)

It would be nice if we could believe that these were isolated incidents. But I can't; I think that they are the inevitable end product of the kind of economic incentives that CAs operate under. There is simply no money to be made from security and from vetting people; security costs money, and vetting your resellers and customers not only costs money, it also loses you money as you have to turn down more resellers and customers instead of taking their money. In the absence of actual costs to this behavior (as opposed to occasional bad press), we should expect that there are far more weak CAs out there that just haven't been exposed yet.


Comments on this page:

From 91.192.241.20 at 2009-01-01 05:46:54:

I generally agree with the article. Being in the business almost since the invention of SSL (ca. 1995), it was clear to me even at that time that the CA is the most "questionable" element of the infrastructure.

What I'd like to add, is that the root of the problem is the design of x.509 infrastructure, which, being legacy of ISO/OSI model, is based on hierarchical model of the world. The very need to have a hierarchy of universally trusted certificate authorities (which is not questioned by most people) is the fundamental weakness of the model. For one thing, it creates opposite incentives for the CA: it wants to me "easy to access" for parties seeking certification, and "trustworthy" to parties checking others' certifications. This leads to situation when it is neither: small businesses and non-commercial users are wining about the price and paperwork, and all the rest - about insufficient rigorousness of the checking process.

For another thing, hierarchical structure creates a "single point of failure" situation, when a failure of a node in the tree largely invalidates trust in all the nodes below it.

Basically the model is OK for, e.g. military applications, where every part of the structure is under strict administrative control. But is fails in the open world where trust relationships cannot be forced into a hierarchy.

Which leads us to to "other" trust models: PGP "web of trust" and SSH "one to one" paradigms. While both of them have their own sets of problems, and may indeed be less strict than the x.509 hierarchical model, I believe that being deployed in real world, they would be more suitable, and ultimately more trustworthy than the current model.

=crosser

By cks at 2009-01-02 01:16:49:

Unfortunately I think that in practice, you need something that is quite like a CA. My thoughts on why are long enough that I put them in an entry, SSLCANeed.

Written on 31 December 2008.
« One of Python 3's fundamental problems on Unix
Flaws in the 'web of trust' approach to trust issues »

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

Last modified: Wed Dec 31 21:38:36 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.