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 consultant, entrepreneur, technologist, author and game designer. He's a member of the BlackHat Review Board and helped create the CVE and many other things. He currently helps organizations improve their security via Shostack & Associates, and advises startups ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
HackerOne Drops Mobile Voting App Vendor Voatz
Dark Reading Staff 3/30/2020
Limited-Time Free Offers to Secure the Enterprise Amid COVID-19
Curtis Franklin Jr., Senior Editor at Dark Reading,  3/31/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5347
PUBLISHED: 2020-04-04
Dell EMC Isilon OneFS versions 8.2.2 and earlier contain a denial of service vulnerability. SmartConnect had an error condition that may be triggered to loop, using CPU and potentially preventing other SmartConnect DNS responses.
CVE-2020-5348
PUBLISHED: 2020-04-04
Dell Latitude 7202 Rugged Tablet BIOS versions prior to A28 contain a UAF vulnerability in EFI_BOOT_SERVICES in system management mode. A local unauthenticated attacker may exploit this vulnerability by overwriting the EFI_BOOT_SERVICES structure to execute arbitrary code in system management mode.
CVE-2020-8142
PUBLISHED: 2020-04-03
A security restriction bypass vulnerability has been discovered in Revive Adserver version < 5.0.5 by HackerOne user hoangn144. Revive Adserver, like many other applications, requires the logged in user to type the current password in order to change the e-mail address or the password. It was how...
CVE-2020-8143
PUBLISHED: 2020-04-03
An Open Redirect vulnerability was discovered in Revive Adserver version < 5.0.5 and reported by HackerOne user hoangn144. A remote attacker could trick logged-in users to open a specifically crafted link and have them redirected to any destination.The CSRF protection of the “/...
CVE-2020-8147
PUBLISHED: 2020-04-03
Flaw in input validation in npm package utils-extend version 1.0.8 and earlier may allow prototype pollution attack that may result in remote code execution or denial of service of applications using utils-extend.