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.

Attacks/Breaches

4/3/2015
09:05 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

Google Spat With Chinese Firm Highlights Digital Certificate Security Challenges

Chrome will no longer trust certs issued by CNNIC following recent snafu, and Mozilla Firefox will revoke certs issued by the Chinese authority before April 1.

A decision by Google to drop a Chinese root certificate authority (CA) for its role in the recent issuance of unauthorized digital certificates for several Google domains underscores yet again the brittle nature of the Internet trust model. Mozilla also announced that it will take action against the CA.

Google yesterday said that its Chrome browser would no longer recognize certificates issued by China Internet Network Information Center (CNNIC). The change will take effect in a future Chrome update, according to Google.

"For a limited time we will allow CNNIC’s existing certificates to continue to be marked as trusted in Chrome, through the use of a publicly disclosed whitelist," Google security engineer Adam Langley said in a blog update this week.

CNNIC will have an opportunity to apply for re-inclusion as a trusted certificate authority for Chrome in future, once the company has implemented suitable technical and procedural controls, Langley said.

Mozilla, meanwhile, also said it is taking action against CNNIC for the errant certificates. But the browser maker stopped short of completely removing CNNIC's certificates from its root store. Instead, Mozilla said it would update Firefox so the browser will not trust any certificate issued before April 1, 2015 by CNNIC's roots. Like Google, Mozilla also said CNNIC could apply for full inclusion once it completes certain additional steps to improve its processes.

Google's move evoked sharp criticism from CNNIC. "The decision that Google has made is unacceptable and unintelligible to CNNIC," the company said in a statement. "For the users that CNNIC has already issued the certificates to, we guarantee that your lawful rights and interests will not be affected," the company said, without specifying how. 

Both browser makers were responding to a recent incident where a CNNIC customer, Egypt-based MCS Holdings, accidentally issued unauthorized digital certificates for several Google domains using an unrestricted intermediary certificate authority granted to it improperly by CNNIC. 

Digital certificates are a fundamental component of the Internet trust model. Web browsers rely on digital certificates to authenticate websites and to encrypt communications between websites and browsers. Websites use certificates like those issued by a CA like CNNIC to basically vouch for their identity so browsers know to trust them.

The unauthorized certificates that were issued by MCS potentially could have let someone set up fake Google domains and intercept communications between and to the domains. "CNNIC is included in all major root stores and so the [wrongly issued] certificates would be trusted by almost all browsers and operating systems," Langley wrote in a blog post last week explaining the issue.

The problem resulted from MCS's mishandling of an unrestricted intermediate certificate that Google and Mozilla say CNNIC should never have issued to MCS in the first place.

"We have concluded that CNNIC’s behavior in issuing an unconstrained intermediate certificate to a company with no documented PKI practices and with no oversight of how the private key was stored or controlled was an 'egregious practice,'" Mozilla wrote in its bog.

Google’s decision to pull CNNIC's certificates from its root store makes sense, says Dan Kaminsky, DNS expert and chief scientist at security vendor White Ops.

"Managing certs is an extraordinarily high-touch business with very serious requirements for correctness," Kaminsky says. "Mistakes can be very painful to correct, as revocation does not work in practice."

Certificate authorities like CNNIC get paid to do a job, and if they can't do it, somebody else needs to get paid to do it, he says. "This is likely to further moves by browser vendors to be more involved managing and overseeing the global population of certificates."

Andrew Sullivan, fellow at Internet performance company Dyn, says the entire episode highlights the somewhat fragile nature of trust on the Internet.  "CAs are never supposed to screw up," he says. As an entity authorized to issue the certificates that websites use to authenticate their identity on the Web, a CA is in a position of enormous responsibility.

"The entire web of trust depends on the CA never screwing up because if they do we are all hosed," Sullivan says.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
4/6/2015 | 3:22:55 PM
Added Security
Does this change denote that Chrome and Firefox will block sites that use certs from CNNIC or will this still be dictated by browser settings? If the latter is still the case it is important to note, at least for Chrome users, that they should have the Check for Certificate Revocation Checked in the advanced settings.
Stop Defending Everything
Kevin Kurzawa, Senior Information Security Auditor,  2/12/2020
Small Business Security: 5 Tips on How and Where to Start
Mike Puglia, Chief Strategy Officer at Kaseya,  2/13/2020
5 Common Errors That Allow Attackers to Go Undetected
Matt Middleton-Leal, General Manager and Chief Security Strategist, Netwrix,  2/12/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
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
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. 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-2019-5613
PUBLISHED: 2020-02-18
In FreeBSD 12.0-RELEASE before 12.0-RELEASE-p13, a missing check in the ipsec packet processor allows reinjection of an old packet to be accepted by the ipsec endpoint. Depending on the higher-level protocol in use over ipsec, this could allow an action to be repeated.
CVE-2020-7450
PUBLISHED: 2020-02-18
In FreeBSD 12.1-STABLE before r357213, 12.1-RELEASE before 12.1-RELEASE-p2, 12.0-RELEASE before 12.0-RELEASE-p13, 11.3-STABLE before r357214, and 11.3-RELEASE before 11.3-RELEASE-p6, URL handling in libfetch with URLs containing username and/or password components is vulnerable to a heap buffer over...
CVE-2019-10792
PUBLISHED: 2020-02-18
bodymen before 1.1.1 is vulnerable to Prototype Pollution. The handler function could be tricked into adding or modifying properties of Object.prototype using a __proto__ payload.
CVE-2019-10793
PUBLISHED: 2020-02-18
dot-object before 2.1.3 is vulnerable to Prototype Pollution. The set function could be tricked into adding or modifying properties of Object.prototype using a __proto__ payload.
CVE-2019-10794
PUBLISHED: 2020-02-18
All versions of component-flatten are vulnerable to Prototype Pollution. The a function could be tricked into adding or modifying properties of Object.prototype using a __proto__ payload.