Last month, a major CA (Comodo) suffered a security breach when a certificate reseller account was compromised and used to fraudulently issue SSL certificates for high value domains, including www.google.com and login.yahoo.com. Adding to the raft of security breaches suffered by other security vendors (RSA, Barracuda), this breach has rightly so sparked additional attention to the inherent security of PKI and security systems in general. In this particular attack, the CA itself was not directly compromised but rather the account of a registration authority (RA) was breached. In standard PKI workflows, the CA is responsible for receiving certificate enrollment requests, forwarding the requests to a RA (also known as a vettor), and issuing certificates once the RA has approved the request. For online certificate enrollment systems operated by CAs and occasionally bundled into domain name registrations, certificate resellers may host a certificate enrollment site as well as have access to a ‘certificate vettor’ interface both provided by a CA. This vettor interface is an administrative interface that permits the RA to examine the details of the certificate request which they can use to perform identity validation and other checks as required by the CA’s certificate policies/practice statements. This model means the CA can outsource the vetting and enrollment processing to partners/resellers.
In the Comodo incident, it’s quite possible the attacker was able to obtain credentials to the reseller’s vettor interface (I’m not with Comodo so this is speculation on my part). This would enable them to submit certificate enrollment requests for domains they didn’t own and immediately approve them. Luckily, the fraudulent certificates were discovered 15 minutes after issuance according to Comodo. Comodo isn’t saying how the fraudulent certificates were discovered, but most likely there are audit tools that scan issued certificates against a whitelist of known high value domains.
The implication of this attack and it’s effect on the industry has served to cause site operators to seriously question the value of CAs and look at alternative trust models. As explained in my other post, the current CA trust model requires users to trust their browser, operating system, and device vendors to include a list of ‘trusted’ CA root certificates in their products. Site operators which wish to use SSL certificates to secure their websites must purchase certificates from one (or more) of these CAs, during which they prove domain ownership and, in the case of extended validation certificates, additional authentication information. In this model, note that end users (who have the most to lose from accessing fraudulent websites), have no power to choose who they trust (the decisions are made for them by site operators and browser vendors). Nominally, this is actually a good thing since end users generally can’t be expected to have enough information to make sensible trust decisions.
The biggest weakness that this trust model has exposed as a result of the Comodo incident is the difficulty in providing an effective way for fraudulently issued certificates to be revoked. While both CRLs and OCSP were used to revoke the certificates, the fact is that many end user devices do not regularly fetch certificate revocation information due to complexities with maintaining effective access to CRL/OCSP responders and continuing debate on how CRL/OCSP failures should be handled in browsers.
With that background, a couple of alternative trust schemes are being proposed within the IETF. Perhaps the most promising scheme is DANE (DNS based Authentication of Named Entities). The cool thing about DANE is that it leverages another major security protocol overhaul that’s been happening for the last 8 years or so (DNSSEC). Essentially, DANE provides a mechanism for a domain registrar to add a certificate/public key for a given website to that site’s DNS record. Since DNS lookups themselves will be secured using the underlying DNSSEC mechanisms (and the contents of the DNS records will be authentic and integrity protected via DNSSEC services), the DNS records are as safe a place as any to store key material used to secure a site (or any client resource that can use keys to secure connections). The controversy that I’m seeing with the DANE proposals is that the trust model doesn’t require a CA to issue certificates used to secure a site. In fact, DANE fully supports the notion of self signed certificates. The idea is that if you trust that the owner of the domain has already passed necessary validation to get a DNSSEC secured DNS record, why can’t you simply trust the owner to provision a key for his/her site especially since that key is protected by DNSSEC resources?
There are still lots of open questions and discussions around DANE, and the CA vendors are making strong arguments that their services are still required even in a DANE enabled ecosystem (the anti-fraud checks performed by CAs before issuing certificates are unlikely to be performed by DNS registrars and obviously a site operator would not need to perform such checks).
I know that I’ll be following the development of DANE and discussions on the IETF DANE lists.