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 an entrepreneur, technologist, author and game designer. He's a member of the BlackHat Review Board, and helped found the CVE and many other things. He's currently building his fifth startup, focused on improving security effectiveness, and mentors startups as a ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
12 Free, Ready-to-Use Security Tools
Steve Zurier, Freelance Writer,  10/12/2018
Most IT Security Pros Want to Change Jobs
Dark Reading Staff 10/12/2018
Most Malware Arrives Via Email
Dark Reading Staff 10/11/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-15378
PUBLISHED: 2018-10-15
A vulnerability in ClamAV versions prior to 0.100.2 could allow an attacker to cause a denial of service (DoS) condition. The vulnerability is due to an error related to the MEW unpacker within the “unmew11()?? function (libclamav/mew.c), which can be exploited to trigger an inval...
CVE-2018-18073
PUBLISHED: 2018-10-15
Artifex Ghostscript allows attackers to bypass a sandbox protection mechanism by leveraging exposure of system operators in the saved execution stack in an error object.
CVE-2018-15593
PUBLISHED: 2018-10-15
An issue was discovered in Ivanti Workspace Control before 10.3.10.0 and RES One Workspace. A local authenticated user can decrypt the encrypted datastore or relay server password by leveraging an unspecified attack vector.
CVE-2018-17961
PUBLISHED: 2018-10-15
Artifex Ghostscript 9.25 and earlier allows attackers to bypass a sandbox protection mechanism via vectors involving errorhandler setup. NOTE: this issue exists because of an incomplete fix for CVE-2018-17183.
CVE-2018-15591
PUBLISHED: 2018-10-15
An issue was discovered in Ivanti Workspace Control before 10.3.10.0 and RES One Workspace. A local authenticated user can bypass Application Whitelisting restrictions to execute arbitrary code by leveraging multiple unspecified attack vectors.