January 05, 2013

Yet another CA snafu

In the closing days of 2012, another CA was caught out making mistakes:

2012.5 -- A CA here issued 2 intermediate roots to two separate customers 8th August 2011 Mozilla mail/Mert Özarar. The process that allowed this to happen was discovered later on, fixed, and one of the intermediates was revoked. On 6th December 2012, the remaining intermediate was placed into an MITM context and used to issue an unauthorised certificate for *.google.com DarkReading. These certificates were detected by Google Chrome's pinning feature, a recent addition. "The unauthorized Google.com certificate was generated under the *.EGO.GOV.TR certificate authority and was being used to man-in-the-middle traffic on the *.EGO.GOV.TR network" wired. Actions. Vendors revoked the intermediates microsoft, google, Mozilla. Damages. Google will revoke Extended Validation status on the CA in January's distro, and Mozilla froze a new root of the CA that was pending inclusion.

I collect these stories for a CA risk history, which can be useful in risk analysis.

Beyond that, what is there to say? It looks like this CA made a mistake that let some certs slip out. It caught one of them later, not the other. The owner/holder of the cert at some point tried something different, including an MITM. One can see the coverup proceeding from there...

Mistakes happen. This so far is somewhat distinct from issuing root certs for the deliberate practice of MITMing. It is also distinct from the overall risk equation that says that because all CAs can issue certs for your browser, only one compromise is needed, and all CAs are compromised. That is, brittle.

But what is now clear is that the trend started in 2011 is confirmed in 2012 - we have 5+ incidents in each year. For many reasons, the CA business has reached a plateau of aggressive attention. It can now consider itself under attack, after 15 or so years of peace.

Posted by iang at January 5, 2013 04:14 PM | TrackBack
Comments

To mitigate these attacks, technology like DANE needs to be deployed sooner rather than later. (Disclaimer: I'm one of authors of the DANE/TLSA RFC)

Posted by: Jakob Schlyter at January 6, 2013 04:09 AM

I don't disagree - I'd say that if the vendors deployed any technology it would be helpful. The problem is, they won't. Unless they break ranks like google has, sometimes, not all the time.

Posted by: Iang (very old very simple and very ignored idea for improving user security...) at January 6, 2013 04:35 AM

hope you're aware your own https://financialcryptography.com/ SSL cert went sour - sec_error_untrusted_issuer

Posted by: A.T. at February 1, 2013 04:17 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.