More Certificate Authority Blues

I’ve written here before about the role that Certificate Authorities [CAs] play in supplying credentials used for secure Internet connections via the SSL/TLS protocols, which create an encrypted connection between the user’s browser and the server, while providing the user with some assurance that she is actually connecting to her bank’s Web site, and not some Bad Guy’s imitation.  Unfortunately, we have seen a number of problems with this system, ranging from the hacks of VeriSign, and of the Dutch CA DigiNotar, to the use of a certificate, stolen from the Malaysian government, to sign malicious software.

There have been a number of responses to this.  The Mozilla organization, developer of the Firefox browser, has requested that all CAs providing root certificates to be trusted by the browser perform a security audit of their operations.   Mozilla, Google, Microsoft, and Adobe, among others, have modified their software to reject certificates issued by the now-defunct DigiNotar.  And an industry group, the CA/Browser Forum, comprised of browser makers and CAs, has proposed a new set of standards [PDF] for the issuance and management of trusted certificates, which are meant to be “… an industry-wide baseline standard for the operation of CAs issuing SSL/TLS digital certificates natively trusted by the browser”.

Now, according to an article at Ars Technica, another CA is being criticized for issuing a credential that would allow one of its customers to impersonate others’ Web sites.  Ironically, the practice came to light when the CA, Trustwave, announced that the certificate in question was being revoked, and provided more detail in a follow-up blog post.

Critics are calling for the ouster of Trustwave as a trusted issuer of secure sockets layer certificates after it admitted minting a credential it knew would be used by a customer to impersonate websites it didn’t own.

The so-called subordinate root certificate allowed the customer to issue SSL credentials that Internet Explorer and other major browsers would accept as valid for any server on the Internet.

The certificate was apparently created for a Trustwave customer who wanted to use it in conjunction with a data-loss prevention system.  With the certificate, a proxy server provided by the customer could appear as a desired Internet site to a user’s browser, and as the user to the Internet site; in other words, it could implement a classic “man in the middle” attack.  Trustwave says, and I feel sure that this is true, that there was no malicious intent involved, and that the customer’s users were notified that their connections could be monitored.  They also say that special precautions were taken to prevent anyone from learning the private cryptographic key used to sign the certificate.

The data-loss-prevention system used a hardware security module to ensure the private key at the heart of the root certificate wasn’t accidentally leaked or retrieved by hackers.

Again, I do not suspect anyone of malicious motives, but security procedures have been known to contain flaws, and leaking a key that can be used to sign other certificates would be a very Bad Thing.

I’m hoping that the issuance of this certificate was a one-off dumb decision on Trustwave’s part that will not be repeated.  The company has revoked the questionable certificate, and has said that it will not issue any more certificates of this type.

Trustwave has decided to be open about this decision as well as stating that we will no longer enable systems of this type and are effectively ending this short journey into this type of offering.

I mentioned earlier the proposed standards of practice from the CA/Browser Forum, of which Trustwave is a member.  The standards are quite clear that allowing the creation of certificates for Web sites one does not own is not allowed.  For example, in Section 7.1.2, Certificate Warranties, the standard says:

Right to Use Domain Name or IP Address: That, at the time of issuance, the CA (i) implemented a procedure for verifying that the Applicant either had the right to use, or had control of, the Domain Name(s) and IP address(es) listed in the Certificate’s subject field and subjectAltName extension (or, only in the case of Domain Names, was delegated such right or control by someone who had such right to use or control); (ii) followed the procedure when issuing the Certificate; and (iii) accurately described the procedure in the CA’s Certificate Policy and/or Certification Practice Statement;

There have been some suggestions, though, that the practice of issuing certificates of this kind is not uncommon; if true, they are very disturbing.

This incident is another bit of evidence that there are some fundamental problems with the current CA system.  There are just too many CAs, and not all of their procedures will stand very much scrutiny.