Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

4/4/2016
03:00 PM
Adam Shostack
Adam Shostack
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

CAs Need To Force Rules Around Trust

Google Symantec flap reveals worrisome weakness in the CA system.

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.

Adam 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 ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 11/19/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
The Yellow Brick Road to Risk Management
Andrew Lowe, Senior Information Security Consultant, TalaTek,  11/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: He hits the gong anytime he sees someone click on an email link.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-29128
PUBLISHED: 2020-11-26
petl before 1.68, in some configurations, allows resolution of entities in an XML document.
CVE-2020-27251
PUBLISHED: 2020-11-26
A heap overflow vulnerability exists within FactoryTalk Linx Version 6.11 and prior. This vulnerability could allow a remote, unauthenticated attacker to send malicious port ranges, which could result in remote code execution.
CVE-2020-27253
PUBLISHED: 2020-11-26
A flaw exists in the Ingress/Egress checks routine of FactoryTalk Linx Version 6.11 and prior. This vulnerability could allow a remote, unauthenticated attacker to specifically craft a malicious packet resulting in a denial-of-service condition on the device.
CVE-2020-27255
PUBLISHED: 2020-11-26
A heap overflow vulnerability exists within FactoryTalk Linx Version 6.11 and prior. This vulnerability could allow a remote, unauthenticated attacker to send malicious set attribute requests, which could result in the leaking of sensitive information. This information disclosure could lead to the b...
CVE-2020-25651
PUBLISHED: 2020-11-26
A flaw was found in the SPICE file transfer protocol. File data from the host system can end up in full or in parts in the client connection of an illegitimate local user in the VM system. Active file transfers from other users could also be interrupted, resulting in a denial of service. The highest...