August 27, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Ending Trust in Certificates

  • May 24, 2001
  • By Kurt Seifried
  • Send Email »
  • More Articles »

By Kurt Seifried (seifried@securityportal.com) for SecurityPortal


There are hundreds of thousands of certificates floating around. The whole premise of certificates is that multiple parties trust a central certificate authority. This form of security and verification is not without issues.

For a while now I've been writing articles about SSL. I've outlined various problems, and explained why SSL in general is a poor solution that should be improved (before we start doing things like online voting -- yikes). The whole premise of certificates is that multiple parties trust a central certificate authority (CA), so that when Alice wants to talk to Bob they can verify each others' certificates through the CA -- in theory proving they are actually taking to the person they claim to be.

This CA has a very important job, especially so with the use of X.509 certificates (currently the most common for SSL, smartcards and so on). Unlike PGP or GnuPG, for example, where you can have multiple entities sign a certificate (such as your mother, your boss, the post office, etc.), with X.509 you are limited to one only. Because X.509 certificates can only be signed by one entity you ultimately have to place all your trust in the signing entity.

Chances are, any CA that is setup to sign certs will sign a lot of certs. Once they have built the infrastructure it essentially costs them nothing to sign certificates. In fact, the only major cost for signing a certificate would be verifying that the end party asking for a signed cert is indeed who they claim to be. Verisign (who owns Thawte, among other companies) now has the majority of the market (the last number I saw was over 95%), and they have made at least one extremely large mistake. In January of this year, they issued two certificates to "Microsoft Corporation". Unfortunately, the person that received these certificates did not work for Microsoft. To quote the security bulletin issued by Microsoft:

The certificates could be used to sign programs, ActiveX controls, Office macros, and other executable content. Of these, signed ActiveX controls and Office macros would pose the greatest risk, because the attack scenarios involving them would be the most straightforward. Both ActiveX controls and Word documents can be delivered via either web pages or HTML mails. ActiveX controls can be automatically invoked via script, and Word documents can be automatically opened via script unless the user has applied the Office Document Open Confirmation Tool.

Now, this is a pretty bad situation. But things get worse:

VeriSign has revoked the certificates, and they are listed in VeriSign’s current Certificate Revocation List (CRL). However, because VeriSign’s code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser’s CRL-checking mechanism to download the VeriSign CRL and use it. Microsoft is developing an update that rectifies this problem. The update package includes a CRL containing the two certificates, and an installable revocation handler that consults the CRL on the local machine, rather than attempting to use the CDP mechanism.

Oh dear. The sad part is this: even if Verisign had included a CDP field in the certificate it wouldn't have mattered much since Microsoft doesn't support certificate revocation very well yet.

See, certificates sometimes need to be revoked. Perhaps your laptop gets stolen, you accidentally expose it, or someone that had access to it is fired and you don't completely trust them. This is supposed to be achieved through a "Certificate Revocation List" -- basically a list of certificates that have been revoked, which is signed by the CA (so an attacker can't issue a fake revocation). Well this is all fine and dandy in theory but there are significant problems:

  1. In each certificate there needs to be a field telling you where to look for the revocation (the CDP). As yet there are no large central repositories available for public use, and only a handful (or less) of vendors that even bother to put the field in their certificates (Baltimore Entrust is the only one I know of).

  2. CA's need to create massive, redundant and extremely secure CDP's (having one server just won't do it). The response time for checking whether a certificate is revoked needs to be very fast (even if you only check once a day).

  3. People need to turn on "check for certificate revocation" in their SSL enabled software (web browsers, operating system, email clients, etc.).

None of these problems can be easily solved. There are hundreds of thousands of certificates floating around, and no easy way to find where a certificate's revocation can be found. Many of these certs have reasonably short life span, but not all of them. In the future, hopefully all vendors will issue certificates with CDP fields, but this hasn't happened yet and isn't likely to happen anytime soon. The CA's would need to build massive infrastructures to run their CDP's and support CRL's properly, and this costs real money. Once the CDP's and CRL's are built and available, users then need to use them, turning on "check for certificate revocation" in all their software (it is unlikely vendors will turn this on by default).

Why am I being so pessimistic? Simply put, users will not demand these features. CA's will perpetuate the myth that certificates can be trusted and are suitable for use in business transactions, contracts and so on. Most software vendors have not even provided the capabilities, until recently, if at all, to check for revoked certificates, so even with CA's adding CDP fields it won't help much until people are using software capable of utilizing it. Between software vendors and CA's I don't think the situation is likely to improve anytime soon.



Links

http://www.baltimore.com/devzone/pki/ - excellent information on PKI, CA"s, CRL's, CDP's, etc.

http://www.counterpane.com/pki-risks.html - Ten risks of PKI

http://www.microsoft.com/technet/security/bulletin/MS01-017.asp - Microsoft's security bulletin

http://www.securityportal.com/cover/coverstory20001218.html - The end of SSL and SSH?

http://www.securityportal.com/closet/closet19990930.html - Is SSL dead?

http://www.securityportal.com/closet/closet19991007.html - SSL Redux


SecurityPortal is the world's foremost on-line resource and services provider for companies and individuals concerned about protecting their information systems and networks.
http://www.SecurityPortal.com
The Focal Point for Security on the Net (tm)






Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel