Google Symantec flap reveals worrisome weakness in the CA system.

Adam Shostack, Leading expert in threat modeling

April 4, 2016

4 Min Read

There was some talk a few months ago about Google's decision to revoke a Certificate Authority (“CA”) certificate. That went quiet, which I think is a shame. 

Before I get into the details and some analysis, I want to be clear that I want to discuss the Certificate Trust Infrastructure, not Symantec, whose certificate is being revoked.  I have no knowledge or opinion about their culture or motivations, and I don't mean to impugn either in what I'm writing here.  All of what I say could apply to any certificate authority.

Also, before I get into it, I want to say that I've recently read Philip Rogaway's excellent paper The Moral Character of Cryptographic Work, and so I'm going to talk about a "Certificate Trust Infrastructure" ("CTI") rather than "Public Key Infrastructure," since the latter term neuters the import of the system. I'm using the term trust here because the betrayal of these systems matters to you.  A misused CA certificate can break the security of every or any computer on which it’s installed.

So the story, in a nutshell, is that Symantec operates a part of the CTI and so does Google.  Symantec made some vague statement about "other purposes" to which a specific certificate might be used, and Google objected, then objected more by stating that they would distrust that particular certificate.

What's interesting to me is that Google is choosing to distrust that certificate, and only that certificate. This is the third time that Google has scolded Symantec in public in about as many months. (Curiouser and curiouser, as Alice said.)

So what's curious is that, through all of this, Google is taking the very moderate step of banning a single Symantec certificate, not all of them.

Now, perhaps the goal is to gradually increase pressure on Symantec, which is an admirable approach, all other things being equal. Here's the trouble: there exists some unknown set of purposes (We'll call them P.) which the CA is unwilling to disclose.  We might thus assume that P is not in the interests of those who rely on the CTI, otherwise, the CA would disclose them.  We cannot know how widespread the use will be, or at how senior a level it was approved.

What A "CA Certificate" Can Do

CAs, or Certificate Authorities are trusted to do the right thing when they sign things. In short, a CA certificate can break your security in two main ways. First, it can lie about the creators of software, and second, it can lie about the identity of web sites enabling phishing and other attacks.  (It can do other things, but for simplicity, think about those two.)  The way it does this is that the authenticity of various things are vouched for by a CA, which signs a certificate, say one labeled "Google" or "Symantec," and your software displays those names for the creator of software, or the owner of a web site.

What we might guess is that there is an employee of the CA who has P as a goal for the time period, and that said employee's bonus, or some fraction thereof, is dependent on P. So once the certificate is revoked, what might happen?  The employee might be given new goals for the year, or not. The business driver that led to P may go away, or it may double down either with carrots, sticks, or both.  We cannot know.  We might believe that Certificate Transparency will detect the P uses of the certificate.

Even if we believe that, there is going to be some period of time between Google's revocation of the certificate and the June 2016 deadline for Certificate Transparency from the CA when there will only be partial protection in place.

P violates the rules. Absent strong evidence that P is not being achieved, it's hard to fathom why this violation of trust is being accepted.  Without knowing what P is, it's hard to decide if it's being attempted or achieved.  There's a claim that Certificate Transparency makes unusual certificates detectable. That's true.

There are other, stronger claims -- such as it will lead to detection, which is perhaps true.  When someone with sufficient moxie looks at the logs, they'll likely notice. (This is of course, the 'no true Scotsman' fallacy: anyone who doesn't notice obviously lacks appropriate levels of skill.)

The CA needs to either come clean about P, or be removed by those who are trusted to select CAs.

Related Content:

Interop 2016 Las VegasFind out more about security threats at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Click here for pricing information and to register.

About the Author(s)

Adam Shostack

Leading expert in threat modeling

Adam Shostack is a leading expert on threat modeling. He's a member of the BlackHat Review Board, and helped create the CVE and many other things. He currently helps many organizations improve their security via Shostack & Associates, and helps startups become great businesses as an advisor and mentor. While at Microsoft, he drove the Autorun fix into Windows Update, was the lead designer of the SDL Threat Modeling Tool v3 and created the "Elevation of Privilege" game. Adam is the author of Threat Modeling: Designing for Security, and the co-author of The New School of Information Security. His personal home page can be found here

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights