Google slaps Symantec for sloppy certs, slow show of SNAFUs
Certs will keep working, but Chrome will be suspicious, soon
Updated Google’s Chrome development team has posted a stinging criticism of Symantec’s certificate-issuance practices, saying it has lost confidence in the company’s practices and therefore in the safety of sessions hopefully-secured by Symantec-issued certificates.
Google’s post says “Since January 19, the Google Chrome team has been investigating a series of failures by Symantec Corporation to properly validate certificates. Over the course of this investigation, the explanations provided by Symantec have revealed a continually increasing scope of misissuance with each set of questions from members of the Google Chrome team; an initial set of reportedly 127 certificates has expanded to include at least 30,000 certificates, issued over a period spanning several years.”
Googler Ryan Sleevi unloads on Symantec as follows:
Symantec allowed at least four parties access to their infrastructure in a way to cause certificate issuance, did not sufficiently oversee these capabilities as required and expected, and when presented with evidence of these organizations’ failure to abide to the appropriate standard of care, failed to disclose such information in a timely manner or to identify the significance of the issues reported to them.These issues, and the corresponding failure of appropriate oversight, spanned a period of several years, and were trivially identifiable from the information publicly available or that Symantec shared.
The post gets worse, for Symantec:
The full disclosure of these issues has taken more than a month. Symantec has failed to provide timely updates to the community regarding these issues. Despite having knowledge of these issues, Symantec has repeatedly failed to proactively disclose them. Further, even after issues have become public, Symantec failed to provide the information that the community required to assess the significance of these issues until they had been specifically questioned. The proposed remediation steps offered by Symantec have involved relying on known-problematic information or using practices insufficient to provide the level of assurance required under the Baseline Requirements and expected by the Chrome Root CA Policy.
The upshot is that Google feels it can “no longer have confidence in the certificate issuance policies and practices of Symantec over the past several years” and it therefore proposes three remedies:
- A reduction in the accepted validity period of newly issued Symantec-issued certificates to nine months or less, in order to minimize any impact to Google Chrome users from any further misissuances that may arise.
- An incremental distrust, spanning a series of Google Chrome releases, of all currently-trusted Symantec-issued certificates, requiring they be revalidated and replaced.
- Removal of recognition of the Extended Validation status of Symantec issued certificates, until such a time as the community can be assured in the policies and practices of Symantec, but no sooner than one year.
What do we mean by Extended Validation? It’s a little feature that allows the browser to confidently show the owner of a HTTPS-secured website next to the green padlock in the address bar. Google Chrome is going to stop showing that text string for Symantec-issued SSL/TLS certificates. In other words, websites that have paid Symantec for certs with Extended Validation won’t see the feature in Chrome.
A normal certificate without the Extended Validation string
A certificate with its Extended Validation text shown in the browser
As for the “reduction in the accepted validity period,” that means various different versions of Chrome will stop trusting Symantec-issued certificates older than the times listed below. Once a Symantec-issued cert is older than the validity period listed, Chrome will stop trusting it, forcing the certificate’s owner to renew it.
|Chrome version||Cert validity period|
|Chrome 59 (Dev, Beta, Stable)||33 months (1023 days)|
|Chrome 60 (Dev, Beta, Stable)||27 months (837 days)|
|Chrome 61 (Dev, Beta, Stable)||21 months (651 days)|
|Chrome 62 (Dev, Beta, Stable)||15 months (465 days)|
|Chrome 63 (Dev, Beta)||9 months (279 days)|
|Chrome 63 (Stable)||15 months (465 days)|
|Chrome 64 (Dev, Beta, Stable)||9 months (279 days)|
“We propose to require that all newly-issued certificates must have validity periods of no greater than 9 months (279 days) in order to be trusted in Google Chrome, effective Chrome 61,” the search giant added.
“This ensures that the risk of any further misissuance is, at most, limited to nine months, and more importantly, that if any further action is warranted or necessary, that the entire ecosystem can migrate within that time period, thus minimizing the risk of further compatibility issues.”
Google reckons this plan will mean “web developers are aware of the risk and potential of future distrust of Symantec-issued certificates, should additional misissuance events occur, while also allowing them the flexibility to continue using such certificates should it be necessary.”
And of course it also gives developers time to arrange new certificates from whatever issuer pleases them most. Symantec has told The Register it is developing a response to Google’s allegations. We will add it to this story as soon as we receive it. ®
Updated to add
Symantec has hit back at Google’s claims, saying they are “exaggerated and misleading.”
“We strongly object to the action Google has taken to target Symantec SSL/TLS certificates in the Chrome browser,” Symantec said in a blog post.
“This action was unexpected, and we believe the blog post was irresponsible. We hope it was not calculated to create uncertainty and doubt within the Internet community about our SSL/TLS certificates.”
The company said that while yes, it had mis-issued 127 certificates, that 30,000 figure was “not true,” and no consumer harm had been done. It claims to operate “in accordance with industry standards,” and will defend its reputation. Symantec is now in discussions with Google to resolve the issue.
February 4, 2016
February 4, 2016
February 4, 2016