SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
Certificate Authority Compromises Are Global In Reach
There has already been a lot written about the compromise at DigiNotar, GlobalSign and Comodo. One day we will look at the summer of 2011 as the time when the PKI collapsed. That's not hyperbole. The problems with certificate authorities and the inherent weakness they present have been known for years--a fact we alluded to as far back as 1997. Browsers accept certificates as trusted in that they have the signing CA certificate in their local browser store. Browsers do not check that a particular
Mike Fratto
September 9, 2011
4 Min Read
There has already been a lot written about the compromise at DigiNotar, GlobalSign and Comodo. One day we will look at the summer of 2011 as the time when the public key infrastructure (PKI) collapsed. That's not hyperbole. The problems with certificate authorities (CAs) and the inherent weakness they present have been known for years--a fact we alluded to as far back as 1997. Browsers accept certificates as trusted in that they have the signing CA certificate in their local browser store. Browsers do not check that a particular CA is authorized to actually issue a particular server certificate. The trust is universal. That is why the attacks on DigiNotar, GlobalSign and Comodo are so serious and have global impact.
When you go to a website for on-line banking, health care or even email, you want to know two things: You want to know that the site you are going to is in fact the site you intend to visit, and you want to make sure that your data is protected using encryption. Let's say for the moment that the encryption part--the cryptographic algorithms and protocols in SSL/TLS--are strong and can't be successfully attacked today. That leaves determining that you are visiting the site you intend to visit. We want to authenticate the destination. That is a thorny problem because there has to be a way to bootstrap the authentication process. The bootstrap process happens with CAs sending their CA certificates to browser and device vendors in some secure manner (courier, challenge response, etc.), and browser vendors inserting the certificates into the browser or device certificate store. This works for bootstrapping, but also means any CA can create a server certificate for any website. If the signing CA certificate is in your certificate store, the server certificate will be trusted by your browser. Read that a few times and digest it.
Our trust is based on the following:
The CA is run properly and has not been subverted. Any CA can create any certificate, but they shouldn't do that and usually don't unless tricked into it, like Verisign was in 2001 when it issued two code signing certificates to attackers posing as Microsoft employees or were successfully attacked like DigiNotar and Comodo.
The transfer of the digital certificates from the CA to the browser/device vendor occurs in a way that proves the CA certificates are in fact legitimate certificates from the claimed CA. Again, a courier may deliver them or some other mechanism is used to validate them. I think CAs and browser/device vendors take great pains to ensure this happens. At least I hope so.
We assume the local browser store has not been subverted and rogue CA certificates have been inserted. This is actually pretty easy. I have done some cursory research and it seems doable.
It doesn't matter that Diginotar is a relatively small CA in the Netherlands. The certificates it issues are global in nature, as are all the other certificates that CAs issue and are included in your browser and device certificate stores. Global. And there is nothing you can do about it. Your website hasn't been attacked, but if someone can forge a server certificate and get it signed by a trusted CA, then all they have to do is get your users to their man-in-the-middle (MITM) server. (That is a different and difficult problem.) The upshot of having each CA present in your browser or device store represents a single point of attack, and as more CAs are brought on-line, the likelihood of those CAs being compromised goes up, which we are seeing now. A certificate that is presented to your browser for https://mail.google.com signed by ElCheapoCA or Thawte (assuming both CAs are in your trusted browser store) will be equally trusted.
Before you ask, no, Extended Validation Certificates do not resolve these fundamental problems. EV certificates address how certificate requests are validated as legitimate requests from authorized company representatives and define required data to be inserted into the certificate that identifies it as an EV cert and the algorithms used. Frankly, the baseline that EV certs require should be the baseline for all certificates and not some feature addition. Regardless, EV certificates do not address root trust issues.
Some experts have offered alternatives to bootstrapping the trust. Dan Kaminsky thinks DNSSEC is a good way to bootstrap trust, and Moxie Marlinspike highlighted some of the problems at BlackHat offered up Convergence. It's on my reading list.
What can you do about rogue certs? Not much. You could install add-ons to Firefox like Certficate Patrol, CipherFox or sslviz that help making manual certificate checks easier. I haven't used them, and I can't vouch for their efficacy. Basically, this isn't a user problem. It's a technical and procedural problem that the CAs, browser vendors and device makers have to fix.
About the Author
You May Also Like
More Insights
