Skip to main content
banner image
venafi logo

Google vs. Symantec: Ensure Security or Avoid Industry Disruption?

Google vs. Symantec: Ensure Security or Avoid Industry Disruption?

April 12, 2017 | Paul Turner

On March 23rd, Google shook up the PKI world by making a proposal to significantly change how Symantec-issued certificates are trusted by Chrome. Since that initial proposal there has been a lot of discussion about whether the action is warranted—in the press, blogs, the Chrome Blink group, etc. There have been differences of opinion about whether Symantec’s actions justify this type of change in trust, whether Google is being heavy handed, and whether the security benefits of the proposed actions outweigh the potential disruption that would occur when Internet users start getting unexpected certificate warnings. 

There are a lot of relevant details to consider, which I’d like cover in the next two or three blog posts. In this post, I’ll delve briefly into the CA/Browser Forum requirements that Symantec is being measured against. I’ll also outline what is known about Symantec’s actions that triggered Google’s proposal. In the next post, I’ll review what Google has proposed and explore what other options we may consider as an industry. In the final post of this short series, we’ll dig into the important topic of what this type of disruption means to us as an industry and the lessons we should take away from this situation.

Before diving into the details, I’ll summarize my perspective so that you’re not wondering where I stand on this issue:

I believe Google’s proposal is warranted for the following reasons:

  1. The integrity of secure certificate issuance is critical to the security of the Internet. There is no alternative today for authenticating servers.
  2. The CA/Browser Forum (CABForum) has standardized requirements for secure certificate issuance to ensure that security, including audits, is required to verify compliance.
  3. Despite Symantec’s long history of being a leader in certificate issuance security (formerly as VeriSign), as a result of apparent personnel and operational issues, they have directly or through their partners issued many certificates that are not in conformance with the CABForum requirement (in some cases because of lack of audits).
  4. Again, likely due to personnel issues, Symantec has not shown transparency or a good track record of rapid remedial action for several of these issues.
  5. Even if Symantec were to attempt to remedy the questionable status of the certificates in question, it is difficult for them to compel site owners who own those certificates to replace them—shy of revoking them, which has challenges since revocation checking is not consistently enabled across all systems that rely on certificates.
  6. Google has proposed a method for ensuring that Symantec certificates issued in the past get replaced in an increasingly expedient fashion through the Chrome browser.
  7. This action reinforces the security of the Internet. Certificates serve as the foundation of authentication and encryption on the Internet. 

Now, let’s dive into the details.

CABForum Baseline Requirements

The CA/Browser Forum (CABForum) was established to standardize the requirements for issuing publicly-trusted certificates. Members include browser “manufacturers” and public certificate authorities (CAs). “Publicly-trusted” means that certificates issued by a CA are trusted by browsers and other systems that use certificates. The CABForum codified their issuance requirements in a document called the Baseline Requirements, which covers a wide range of topics, including how to validate the requester of a certificate, maximum validity periods, algorithms (e.g., SHA-1), CN and SAN contents, etc.

The Baseline Requirements require that all CAs and their representatives (e.g., partners acting as sub-CAs or RAs) are audited for compliance with the requirements each year and that they publicly publish the results of their audits.

Though the CABForum defines the Baseline Requirements, it is not part of its charter to enforce them. So, you might ask yourself, “If these requirements are so important, shouldn’t they be enforced by someone?” The party in a best position to enforce the requirements are the browsers (and other systems that trust CAs). The browsers decide which CAs they will trust—generally relying on required WebTrust audits but also taking into account security issues, such as the DigiNotar compromise. In addition, each time that a browser connects to a site on behalf of a user, it follows a very intricate set of rules and steps to determine if the certificate provided by that site can be trusted. This logic enables specific certificates to be explicitly distrusted, such as the certificates that were misiissued when one of Comodo’s registration authorities was compromised. If a CA violates the Baseline Requirements or is otherwise compromised, it is the browsers and other systems that are in the best position to rapidly remove that CA from their trust stores or implement a set of rules for how certificates from the CA will be trusted and processed.

What did Symantec do?

So why has Google seemingly singled out Symantec with the proposed changes to Chrome? Here’s some perspective on this question: it is important to note that, owing to the critical security role of certificates, Google and other browser vendors have ratcheted up their monitoring of the integrity of certificates over the past few years. As a result, they have taken remedial actions on ANSSI, NIC, CNNIC, WoSign and StartSSL, and others in response to discovered issues. So, this is not an isolated case of action taken against a particular CA, but rather the continual reviewing of the actions of trusted CAs and taking remedial action when issues are discovered.

With Symantec, the discovered issues have unfolded in a cascading fashion. Amongst other issues, much of this started with the discovery of several certificates issued to domains owned by Google and other companies when they were not requested by those companies. As Google, Mozilla, and others began to investigate the circumstances that led to the issuance of those certificates, several other notable irregularities emerged. Mozilla has maintained a very detailed list of the issues. The diagram below provides a summary of some of the issues.

SymantecIssues-170412-3.png

This is not an insignificant set of issues. To be fair, there are several issues that are not unique to Symantec amongst CAs. For example, several CAs were involved in the accidental issuance of SHA-1-based certificates after the deadline when they should no longer be issued. But patterns seen across several of the issues (unauthorized access to CA resources, lack of audits, mis-issuances) raise questions about the integrity of the certificates that were issued during an extended period of time.

In addition to considering the issues, it is important to point out that there were repeated instances where Symantec’s investigations and disclosures were incomplete, requiring repeated inquiries and responses from Google, Mozilla, etc.—with additional important details and issues unfolding with many iterations. This is a very important aspect of this situation. Because of the fundamental role that CAs play in the security infrastructure of the Internet, it is critical that they proactively and thoroughly investigate issues, since they alone have access to all the relevant information. If a CA repeatedly demonstrates that they are not being rigorous in their operations and investigations, it raises serious concerns about the trust that can be placed in the certificates they issue—which is what has occurred in this recent spate of incidents with Symantec.

It is important to note that this is not a condemnation of Symantec. Both Symantec and VeriSign (which they purchased for their CA business) have a long history of leadership in the security industry. It simply appears that Symantec, potentially due to assigned personnel and organization changes, had lapses that caused their operations to not be up to the standards that they and the industry set. They have already taken steps to address the situation, including making personnel and operational changes. The question is where do we (as an industry) go from here. We’ll pick that discussion up in the next blog post. 

Related blogs

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

NIST TLS Infosec Guidelines

New NIST TLS Management Guidelines for InfoSec [Expert Advice]

NIST Guidelines TLS

What Executives Need to Know about New NIST Guidelines for TLS Management

Best Practices for Securing SSH: Defining SSH Policies

About the author

Paul Turner
Paul Turner

Paul Turner writes for Venafi's blog and is an expert in machine identity protection.

Read Posts by Author
get-started-overlay close-overlay cross icon
Receive notifications about SSL

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas magna erat, hendrerit estibulum pharetra consequat ut ut eros nec, tincidunt.

Receive notifications about SSH

Lorem ipsum dolor sit amet, consectetur adipiscing magnaerat, hendrerit ut eros nec, estibulum pharetra consequat ut tincidunt rutrum augue.

Receive notifications about Mobile

Lorem ipsum dolor sit amet, estibulum pharetra consequat ut consectetur adipiscing elit, magna erat, hendrerit ut eros nec, tincidunt rutrum augue.

How often would you like to receive news?

Lorem ipsum dolor sit amet, estibulum pharetra consequat ut consectetur adip aecenas magna erat, hendrerit ut eros nec, tincidunt rutrum augue.

Update Settings To stop receiving all news, unsubscribe here
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat