Security teams, network administrators, and operations teams have busy days ahead. Google’s Chrome development team is fed up with Symantec as a certificate authority and has announced plans to no longer trust current Symantec certificates.
In the past 18 months, Google has tangled repeatedly with Symantec over the way it issues transport layer security (TLS) certificates, with Symantec promising to do better. The latest incident—an investigation into 127 mis-issued certificates—ballooned into “at least 30,000, issued over a period spanning several years,” Ravi Sleevi, a software engineer on the Google Chrome team, wrote on the Blink online forum. As a result, the Chrome developers “no longer have confidence in the certificate issuance policies and practices of Symantec over the past several years.”
Effective immediately, Chrome will stop recognizing Symantec’s Extended Validation certificates. EV certificates are supposed to convey the highest assurance of a site’s authenticity because the certificate holder had to undergo a stringent verification process in order to receive a certificate of that level. Since Google doesn’t trust Symantec’s procedures anymore, Chrome will recognize that the site has a certificate, but won’t treat it as EV.
From the user’s standpoint, that means the name of the domain owner will not appear in green next to the padlock in the browser address bar. Google is effectively downgrading the higher-class certificates issued by Symantec, for a period of at least a year.
A spot check of three major banks showed they all use Symantec EV certificates. Once this change goes in effect, their names will no longer show up in the address bar. For financial institutions that rely on the address bar to show customers their transactions are safe, this change will force them to consider the validity of continuing to use Symantec certificates.
Going forward, Chrome will not accept any newly issued certificates from Symantec and its affiliates that have a validity period longer than nine months. Existing certificates will be fine for now, but Chrome won’t load sites with year-long or multiyear certificates that are issued after this week by Symantec.
Gradual withdrawal
Google doesn’t trust any of Symantec’s certificates at this point, but it can’t reject them all at once. Symantec and other brands it controls -- including GeoTrust, VeriSign, and Thawte -- account for more than 30 percent, by volume, of the valid certificates currently used on the internet. Firefox data cited by Sleevi shows Symantec-issued certificates are responsible for 42 percent of all certificate validations.
The SHA1-to-SHA2 migration was bad enough; imagine the potential mess if millions of Chrome users suddenly couldn’t access a significant number of sites because Chrome was rejecting the sites’ certificates. Instead of demanding that all certificates be replaced by an arbitrary deadline, Google will gradually decrease the allowed “maximum age” of Symantec-issued certificates and tie that to the next few Chrome releases:
- Chrome 59 (all channels, stable release expected June 6): Chrome will trust only Symantec-issued certificates that will expire no later than 33 months (1,023 days) after they were issued. Note that Chrome 59 entered canary phase—the staged rollout where small groups of users start receiving the updates—earlier this week.
- Chrome 60 (all channels, stable release expected August 1): Will trust only Symantec-issued certificates that will expire no less than 27 months (837 days) after they were issued.
- Chrome 61 (all channels, stable release expected September 12): Will trust only Symantec-issued certificates that will expire no less than 21 months (651 days) after they were issued.
- Chrome 62 (all channels, stable release expected October 24): Will trust only Symantec-issued certificates that will expire no less than 15 months (465 days) after they were issued.
- Chrome 63 (dev, beta channels only): Will trust only Symantec-issued certificates that will expire no less than nine months (279 days) after they were issued. Chrome 63 stable, which is expected December 12, will continue to trust Symantec-issued certificates with a validity period of 15 months (465 days).
- Chrome 64 (all channels, no release date available yet): Will trust only Symantec-issued certificates that will expire no less than nine months (279 days) after they were issued.
This schedule gives developers and administrators about nine months to make the necessary adjustments, and they can either replace their existing certificates with a different CA or renew their certificates with Symantec for a shorter-than-nine-month validity period. For administrators already tasked with the challenge of staying on top of expiring certificates and renewing them on time, the fact that Symantec certificates will have to be renewed every nine months (or sooner) should make them reconsider the decision to stick with Symantec. Especially with Let’s Encrypt and plenty of other options to pick from.
Google can make these rules, and the world’s largest banks, retailers, insurers, and cloud providers will likely replace any Symantec certificates they may have because Chrome has the biggest web browser market share right now.
“Google is the 800-pound gorilla on this issue,” said Kevin Bocek, vice president of security strategy and threat intelligence at Venafi, an enterprise certificate reputation provider.
Remediation is hard
The good thing about Google's timeline is that it gives administrators time to identify impacted certificates and make plans to replace them. Even so, replacing certificates and keys on a mass scale is time-consuming and arduous, as it's often a manual process. And—if history is any guide—it hasn’t always been very successful. The U.S. federal government gave itself a mandate to switch all federal websites to HTTPS, and did not meet the deadline. Organizations struggled to fully remediate Heartbleed. Enterprises find it hard to issue, replace, and recover from security incidents involving keys and certificates, Bocek said.
Google’s decision “highlights how critical it is for businesses to be able to replace machine identities—keys and certificates used for SSL/TLS quickly,” Bocek said. “The largest global businesses with very sophisticated IT operations struggle to respond to an external event like this.”
Carry a big stick
Google’s Sleevi refers to the new rules as “remedies,” but let’s call them what they really are: punishments. Google has warned Symantec repeatedly about its shoddy practices regarding certificates, and now is using its control over the most widely used web browser as a stick to show Symantec what happens when CAs don’t follow the rules. Under Chrome’s Root Certificate Policy, root certificate authorities are expected to perform a number of critical functions, including properly ensuring that domain control validation is performed for server certificates, frequently auditing logs for evidence of unauthorized issuance, and protecting their infrastructure to minimize the possibility of fraudulent certificates being issued.
“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,” Sleevi wrote.
Mis-issued certificates pose a critical threat to pretty much everyone on the internet because the certificate holders can impersonate legitimate sites and monitor communications sent to and from legitimate servers.
Symantec could have possibly salvaged the situation if not for the way the CA handled the investigation. Sleevi accused the CA of not proactively disclosing the issues after it discovered them, not providing timely updates, and not providing details necessary to assess the significance of the problem “until they had been specifically questioned.” The proposed fixes also weren't enough.
“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,” Sleevi said.
Failure to learn
Symantec was already under extra scrutiny after it issued test certificates back in October 2015 for third-party domains—including Google—without first obtaining the permission of the domain holders. If someone had maliciously obtained those certificates, that person would have been able to impersonate Google and other affected sites and intercept traffic meant for those sites. Shortly after, Google insisted that Symantec publish all its certificates to its Certificate Transparency log to make it easier to audit what was being issued.
Symantec can regain its standing as a trusted CA if it can provide Google with assurances it has changed its policies. But the way the current timeline stands, penalties will not be lifted for at least a year.
Google has punished CAs for problematic certificates before, most recently with its decision to not trust WoSign and StartCom certificates. The situation with Symantec is different; it is just “too big to fail”—too many sites rely on Symantec and its affiliates—but the repeated violations required some kind of a response. While the gradual mistrust may cause extra work for developers and administrators, who must now stay on top of multiple dates and schedules, it will minimize the risk of a widespread outage.
The internet relies on a fragile system of trust, and when CAs don’t play by the rules, they undermine the whole ecosystem. Google is showing it isn’t afraid to take dramatic steps to force CAs to comply with the rules. Other CAs will be smart to heed that lesson.