Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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:
-
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). -
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). -
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 ™
