Last Updated: 2017-03-27 15:20:55 UTC
by Johannes Ullrich (Version: 1)
Google has long been vocal about Symantec's use of "test certificates". Google alleged that Symantec does not provide sufficient controls to prevent an abuse of its widely respected certificate authority. Late last week, Ryan Sleevi who is part of Google's Chrome team, announced that Google Chrome / Chromium will phase out trust in Symantec's CAs, and at the same time, no longer recognize them for Extended Validation. 
Root Certificate Authorities are critical for TLS to work and have been in my opinion the weak point when it comes to TLS security. I have yet to find a public example of a system being compromised because SSL v3 was still enabled on the system. On the other hand, there are plenty of examples of certificate authorities either getting compromised to issue fake certificates, or weaknesses in certificate authorities validation schemes being abused. Symantec is far from the only certificate authority with issues and trust in certificate authorities has been revoked in the past. The most notable recent case was probably WoSign/StartSSL which didn't comply with accepted procedures to issue certificates.
Symantec is a major certificate authority. Ryan states in his post that "In January 2015, Symantec-issued certificates represented more than 30% of the valid certificates by volume", and "From Mozilla Firefox’s Telemetry, we know that Symantec issued certificates are responsible for 42% of certificate validations". So in short: A lot of sites are using certificates based on Symantec's CA and a lot of people visit sites that use certificates based on Symantec's CA. This is an important issue that will likely have a large impact.
To make things more "interesting", Symantec based certificates are also issued by resellers, and it may not always be obvious to buyers that a certificate is based on a Symantec CA. Some of these Sub-CAs, if they are operated independently from Symantec, are not included in this action. The list of Symantec roots affected is quite substantial .
Regardless if we agree or do not agree with Google's action on this, here are some of the issues you need to be aware off:
- Right now, this is just a proposal. Nothing has been implemented yet, and Google may change its mind, or change its schedule.
- This issue will only affect Google Chrome users. Google Chrome is by some counts currently the most commonly used browser. But it will only affect HTTP(S), not other services like imap that are not supported by Chrome. It will also not affect internal web services that are not used by browsers.
- The most pressing issue right now are Extended Validation certificates. Google proposes to no longer indicate that a certificate is an "Extended Validation" certificate. Users will not see the green URL bar and may not see the company's name in the URL bar. The certificate will however be considered valid. This is likely going to confuse some security minded users, but for the most part, users are likely going to ignore this issue or not notice it at all.
- For all other certificates, Google proposes an elaborate phase-out plan. The phase out plan is based on Google Chrome versions, not on specific dates. In each release, certificates that exceed a certain age, will no longer be trusted.
Chrome Version Release Date Maximum Age Issued Before 59 (dev/beta/stable) June 6th 2017 33 months Sept 6th 2014 60 (dev/beta/stable) August 1st 2017 27 months May 1st 2015 61 (dev/beta/stable) September 12th 2017 21 months Dec. 12th 2015 62 (dev/beta/stable) October 24th 2017 15 months July 24th 2016 63 (dev/beta) 9 months 63 (stable) December 12th 2017 15 months Sept 12th 2016 64 (dev/beta/stable) January 2018? 9 months Oct 12th 2016
These dates may of course change. There is currently no published estimated release date for Chrome 64, so I guessed January 2018 
The most pressing issue right now are Extended Validation certificates. But what you need to do soon (if you don't have it already), is to inventory your certificates by Certificate Authority and time it was issued. The easiest way to do this, in my opinion, is bro. If you have bro running on your network, check the x509 logs for any certificates that may be applicable and extract the issuer and the "not valid before" date. Keeping track of SSL certificates is a good idea anyway, so this exercise isn't all going to be a waste if Google changes its mind.
If you do come across affected certificates: Contact your issuer, see if they have any options like issuing a new certificate signed by a CA that is not going to be blocklisted by Google.