TLDR: Google has lost trust in Symantec's ability to properly validate certificates they issue. Chrome has a Root Certificate Policy that expects a CA to perform in a manner commensurate with the trust being placed in them and the Google team appears to see evidence that they are not living up to the standard laid out.
They propose a gradual distrust of existing certificates by reducing the 'maximum age' of the certificates with each release of Chrome.
EV certificates are proposed to have their EV indicators stripped immediately until Symantec, for one year, demonstrates sustained compliance.
This is a good summary, but I'd clarify it by saying that Google isn't being subjective about Symantec's process failures. The CA industry self-regulates. Its regulatory organization is the CA/B Forum, and their principal regulation is the Baseline Requirements (the BRs). Google claims Symantec violated multiple BRs.
If you want to dig a little deeper, here's the last version of the BRs:
Small correction: the CA industry doesn't self-regulate. Both browsers and CAs participate in the CA/Browser Forum and my (admittedly outsider) impression is that browsers almost always have the upper hand.
But if I understand correctly, this decision was Google's entirely?
If that is the case then it doesn't matter much what forum thinks about Symantec. Buying a certificate which is not supported by a major browser vendor would be... eccentric, so my guess is this will be a major blow for Symantec certificate business.
CA/B is neither a regulator nor, formally, a Standards Development Organisation although if you can squint it can look a little like either. CA/B produces the Baseline Requirements and also a set of EV Guidelines, for how a CA should behave.
The browser vendors (actually mostly OS vendors in their guise as browser vendors, Mozilla effectively stands in for all the Free Unix type operating systems) operate trust roots, and each of them decides their own criteria for things to appear in those roots.
BUT there was concern as the root store programmes began to tighten up their criteria that they might step on each others' toes, CA/B is a forum to share common principles. For example, rather than Mozilla tell CAs to stop issuing certificates that last more than 2 years plus a few days, and Google tell them not to issue ones that last more than 25 months, and then Microsoft say they want a rule forbidding new certificates that last more than 750 days, everybody got together at CA/B and passed a Baseline Requirements change setting the limit at 825 days from next year.
CA/B looks a lot like a cartel (all the companies in an industry meeting up to agree things) so it has a bunch of things it mustn't do to ensure it doesn't break anti-cartel legislation and get anybody sent to jail [The world's most famous cartel, OPEC, doesn't fear the law because OPEC is run by governments and governments have sovereign immunity]. For example it can't talk about prices, or future products.
Another result of not being a cartel is that CA/B doesn't bind either CAs or Browsers. The CAs can break CA/B rules without being kicked out of CA/B and the Browsers can and do require things beyond the Baseline Requirements, for example Microsoft requires every CA in its programme to revoke any certificate it tells them to, on demand.
Initially CA/B was all about smoke-filled rooms (maybe not literally) but Mozilla and Google have pressured them to gradually act more in the open, so you can actually follow along most of their decision making in real time via their mailing lists.
Things that go to vote in the CAB Forum are often split pretty exactly down CA v. browser lines, and the CA outnumber the browsers and hence typically win. That said, the power of the browser vendors as those who maintain the trust stores is obviously there.
This is not accurate. To pass, a ballot must receive a 2/3 majority from CAs AND a 1/2 majority from browsers. While there have been some contentious votes along CA-browser lines, you can see from the ballot history that most ballots have passed and thus had support from both browsers and CAs:
> In the event that a CA issues a certificate in violation of these requirements, the CA SHALL publicly disclose a report within one week of becoming aware of the violation. A link to the report SHALL simultaneously be sent to incidents@cabforum.org.
> From the CAs, there were 0 YES votes, 14 NO votes and 5 Abstentions
> From the Browsers, there were 3 YES votes, 0 NO votes and 0 Abstentions.
The ballot was a bit more nuanced than it seems. 1) Browsers already require reporting of mis-issuance directly to them. Mozilla requires a public bug list and 2) There was insufficient clarity in the ballot about "mis-issuance". Plus with crt.sh, this information is already available in one general location, which made the reporting requirement of everything seem a bit redundant.
If they can't get their way, the browser vendors can just shrug and make their own rules, that's what happened for Ballot 169 for example.
Ballot 169 says to validate DNS names in a certificate you can't just make up any old "validation method" and say you think it's adequate, you must use at least one of these specific enumerated methods.
The Ballot passed, but then a bunch of CAs declared that they had patented some of the methods on the list. So effectively even though it passed Ballot 169 was unwound while they negotiated patent licensing agreements.
But Mozilla meanwhile went "everybody must obey Ballot 169 or get kicked out of Mozilla's trust store", so that raised the bar anyway.
The happy news is that a mix of Mozilla saying "comply or feel free to go out of business, we don't care" and people like me pointing at the crappy patents and laughing at their weak excuse for "innovation" appears to have had the desired effect, and a new Ballot will reinstate the stuff from Ballot 169 later this year.
So after reading this, the following auditors aren't
trusted by Symantec anymore:
- E&Y Korea
- E&Y Brazil
The following isn't trusted by Mozilla anymore:
- E&Y Hong Kong
This seems to be a worrying trend to me.
Kurt
Yes, each of the Big Four isn't really a single company, that'd be too vulnerable to lawsuits when (let's face it, not if) they screw up. Instead they're a network of companies licensed to use the same name.
Mozilla was asked (I do not know if they actually did it) to have one of their London people stroll over to EY's headquarters building in that city and explicitly let them know about the Hong Kong EY's failures so that there's no opportunity to later pretend EY as a network didn't know this was a problem.
The nature of audit work, both for the Web PKI and for business accounting means that "capture" is a big problem, the auditors get paid by the company they're supposed to audit and further work is conditional on giving a good report, so, why look for trouble? Failure is inevitable.
If you're wondering when it became the Big Four, the Big Five had one more member, they audited Enron and signed off accounts which bore no resemblance to reality, then when they realised it was being investigated they destroyed all evidence of what they'd done. The resulting scandal destroyed them, although the US Supreme Court eventually decided that the people who ran the audit firm and gave orders to cover up what it had done were innocent...
EV actually causes a different "secure" UI to display in the browser. Usually it is the name of the corporate entity that the certificate is issued for. If you don't have EV you only get a padlock.
Browsers make changes like that to their UIs all the time. I highly doubt that a member of the general public would notice the difference. Heck, I doubt most developers would notice.
I agree, because I experienced it just now. I'm on Chrome 57 and just realized that Chrome certificate details UI seems to have changed sometime recently.
I remember I could earlier click on the padlock or "Secure" text, click More (or something) on the popup and it would display certificate details in developer tools (which is itself weird, but atleast it was available for end users).
Now, it doesn't give any direct way to see certificate details. "Learn More" just opens a support page with vague details. The only way for a user to see details now is to explicitly launch developer tools. I find this logic a bit weird. Apparently, this is not a bug but a feature [1].
You just made me look, and what I saw made me sad. Even more than I already was. :(
"Let's remove this thing that is super useful while your stated goal could just as easily be reached while keeping the original functionality." Bill Hicks was so incredibly right about marketing.
The business is not the user for SSL. It's the human logging into the website. Maybe Bank of America will care if the padlock in the URL bar is gone, but John Doe couldn't care less and probably has never noticed the green padlock and word secure in the URL bar ever.
Yes, you are correct, in that Symantec's customers will care.
I am saying the customers of banks don't give a damn about EV or not. It's not in the literature. It's hard enough to train them not to click through; even I as an IT guy would probably not notice the lack of EV unless there were a modal or bubble saying "Hey! This is different!"
I worked at a financial institution for several years. There are many, many IT folks, internal auditors, and others who are probably wishing they wore their brown pants to work today.
SSL certificates are cheap in contrast to the labour intensive management practices that exist around them, especially around legacy platforms that may have been hardcoded to use certificates from a specific issuer (not that I have ever seen that before, no one would be that foolish right? :/)
>especially around legacy platforms that may have been hardcoded to use certificates from a specific issuer (not that I have ever seen that before, no one would be that foolish right? :/)
D'ya know, I would have naively assumed this wasn't technically possible. I shudder not only to think of the code, but also of the thought process that could compel someone to undergo the effort of bricking themselves into this corner because honestly, that sounds a lot harder than doing it right.
It happened to me - I was working on an application for the pre-paid electricty system in Texas: the server-side code connects to a data-source over a TLS connection (complete with client-side certificates too), except the server-side used a self-signed certificate, and my code didn't have admin/root rights on the client hardware so it had to use in-app certification verification code. I had to hard-code the root CA's fingerprints directly into my code so it would be baked into the signed binary (this was a project requirement). That thing is going to fall-apart if the root CA ever changes - fortunately it won't expire until 2099.
(Yes, I gave the client a strongly worded statement of my misgivings - and all the other bad code-smells in the project)
Pinning is a good thing, assuming you have built in a reliable upgrade path (oh hey, browsers update themselves automagically now so yay!) but when you have occasionally connected devices that have low bandwidth that have a long deploy lifecycle, it's not always feasible, or even a good idea.
It's even worse if said device is embedded and has severe hardware constraints for compliance and regulatory reasons, and those same reasons prevent you from deploying patches on the regular.
Layer in some "built by the lowest bidder" and "accumulation of 30-odd years of poor practices for smart payment cards" and you have a big mess of a situation to unravel.
Oh yeah, and lest you think this is not an issue because this is browser related, may I introduce you to the world of services that proxy legacy green terminal applications into web front ends, ranging from IBM HATS to bespoke AJAXy things that unwrap screen scraped terminal emultor content from XMLHttpRequests.
Jeez. Remembering why I used to drink more when I worked in fintech :)
Except that that likely ended up baked into a system that is hard or impossible to upgrade. So when the certificate is revoked or changed the system stops working.
This is essentially what HTTP Public Key Pinning (HPKP) does [0]. HPKP is a header your web server responds with that tells the client's browser, "Only trust my domain if the certificate presented is in a chain that goes up through one of these CA public keys". This is so an attacker can't go buy a certificate from a less-diligent CA and use that to MITM HTTPS traffic between clients and your domain.
You pick two or more CAs you trust, and brick yourself into a corner saying "these are the only CAs you should ever trust w.r.t. this domain".
Hardcoding certificates is actually way too easy. SSL libraries don't necessarily use the system ca store or even know about it. OpenSSL has the option of disabling certifcate validation, providing your own certificate list or pointing to some system-supplied certificates which you need to find first. So in a way you even have to count yourself lucky if the hardcoded one instead of choosing to just disabling validation.
It's pretty common in the embedded world where you don't have enough flash space-- or don't want to use what flash you have-- to hold a root CA store.
Such devices are usually great targets for learning how not to secure things, because when they care that little they often don't get anything else right either.
I'm fairly sure at least some of the "policy violations" that Symantec did were done exactly as a service to their large bank-or-close-enough customers.
It's not that banks want to switch to a "better" SSL service, it's Symantec being a "better" service for them that got Symantec into trouble.
Symantec took one of their widely trusted root certificates and declared that it was now "off the reservation", meaning they may choose to not comply with the BRs for its leaf certificates.
I don't know if they have actively used it to issue SHA-1 certificates, but they certainly could.
The exception process used by payment processors such as First Data were for SHA-1 certificates chaining to a root that was still publicly-trusted. They couldn't use an off-reservation root because their client devices didn't trust them.
I may be being a bit dense, but if your client device contains a root that goes off-reservation, how does it ever receive a revocation notice? Doesn't everything that chains to that root via a valid chain still get trusted?
Side note: Are payment systems required to link to revalidate their roots at any regular intervals?
> I may be being a bit dense, but if your client device contains a root that goes off-reservation, how does it ever receive a revocation notice? Doesn't everything that chains to that root via a valid chain still get trusted?
Yes, if a client isn't receiving root store updates it will continue to trust certificates chaining to the off-reservation root. This is why taking previously-trusted roots off-reservation is bad for the ecosystem and would ideally be prohibited.
> Side note: Are payment systems required to link to revalidate their roots at any regular intervals?
Many payment systems apparently have no automatic update mechanism, so I assume there is no requirement for such.
Indeed, I was just speculating that more banks and payment processors might take advantage of the off-reservation root if it was possible, given the type of companies that publicly showed they needed one.
However, there's no point in pretending these certs are good if we can't trust the issuer to not put out BAD certs. Painful or not, if the banks are user the certs to show they are trustworthy, then they need to switch when the issuer ISN'T trustworthy.
Not always, although it depends on what you are changing. I work for a 200,000 person company, and switching cert providers would not be a huge task. We have done it before.
The max time also starts at 33 months w/ Chrome 59 so thankfully they're giving plenty of time to either resolve the situation or have people switch CAs.
Not really. By the end of the year with their schedule Chrome 64 will be out with 9 month validity. Then who knows after that. So it is at the most 18 months.
This is huge, Symantec owns about 15% of the SSL certificate market[1], and as stated in the article, has issued 30% of in-use certificates. No certificate authority of this size has ever been raked over the coals like this.
Pretty much it will decide the question on whether or not the certificate system is even workable. My thesis is that either Symantec will not be able to respond (and so lose their ability to be a root certificate) in which case it will warn other root cert authorities to shape up or lose their business, or they will placate the Google and Chromium teams somehow and show that root cert authorities can be brought to bear.
Or they will ignore Google, continue to create bad certs, and users will start getting instructed by sites that they have to manually add a root certificate in order to use they site, and the entire ecosystem will collapse.
Sans maybe spear phishers, spam campaigns aren't generally ran by oppressive governments. MiTM certs with bogus certs absolutely are, and could result in jail / death.
Could actually dodgy sites then imitate bank websites, ask the same of users and then commit a MITM attack?
I'd much rather be able to say -- 'no, never manually trust a cert', instead of 'well, ok, for now yes in this one case if you're sure there's no typos in the URL... What? Yeah, the text at the top in the little bar... argh'.
I hope I'm missing something here, but even better I hope Symantec and banks get their acts together.
Could actually dodgy sites then imitate bank websites, ask the same of users and then commit a MITM attack?
Technically, certificate pinning etc can prevent this, but in practice, yes, this is a possible attack vector.
But it has little to do with CA validation. If the user understands how to verify the domain and security of the connection the attack doesn't work, and if he doesn't, the Google vs Symantec situation makes no difference either.
That's a good insight. Apple and Mozilla don't seem to mind making big decisions for their users on behalf of perceived security threats either, so I imagine only Edge will hold out for long time. Google probably won't lose any market share over this.
I think it's likelier that Symantec will start a negative PR campaign, leading its users to yell at google to change things, perhaps calling this FUD. Whether that'll be effective is another question.
>Symantec will start a negative PR campaign, leading its users to yell at google to change things,
It seems Google has the leverage, not Symantec.
A PR awareness campaign is out-of-band information that's separate from the web surfer actually navigating to a site. Millions of users would see a scary message similar to "This site's security certificate is not trusted!"[1].
To prevent scary security popups, which is more likely?
1) The website owners abandon Symantec and switch to a Certificate Authority not flagged by Chrome
or
2) Users get "educated" on Symantec's side of the story and manually add Symantec as a trusted root certificate. (Some can switch browsers but for many non-techies, that's a pain because they have all their bookmarks in Chrome -- and migrating them on mobile phone is not obvious.)
3) Large websites using Symantec certs start telling users Chrome is "broken" and we find out if users will switch browsers, not care about the security, and/or complain to the sites.
I definitely find any variation of #3 to be more likely than #2. I see it as a battle between #1 and #3.
>Large websites using Symantec certs start telling users Chrome is "broken"
I'm having a hard time thinking of a scenario where a large website concludes it's cheaper to convince web shoppers at ecommerce sites and web visitors at news sites to switch to Firefox/IE instead of the website just switching CA vendors.
If you're a website that wants to put up zero friction between buyers submitting their credit-card info and pay you money, why try to "educate" them? If you're a website that wants visitors to see your ads next to your journalists' stories, why make it more difficult than it has to be? Does Symantec as a CA offer up extra benefits that no other CA has such that it makes sense to "train" web visitors to switch browsers?
Of the millions of non-geeks that use Android phones, what % download and use Firefox instead of the default Chrome browser?
This line of reasoning works for banks or commercial entities.
But note, it does not work for governments. They can, and will, put up a red banner instructing the user to install another browser (or in case of Firefox 52, explain how to disable updates so you can keep using NPAPI plugins).
Interesting point. I spot checked CAs for some of the most popular USA government websites.
irs.gov (Internal Revenue Service): Entrust CA
va.gov (Veterans Affairs) : Symantec CA
So if Symantec is the CA for a critical mass of government websites that won't abandon them, Google Chrome could lose this battle.
Without looking at traffic data (e.g Alexa), my intuition says the vast majority of web traffic is not government websites. If Veterans Affairs forces user to switch browsers, I'm guessing people would still use their Chrome browser for all the other websites because that's where all their bookmarks live.
As for non-government websites, I notice that Netflix.com currently has a Symantec Class 3 CA. I'm guessing Netflix would rather switch to another CA.
The US Federal Government has stated a long term plan to operate a CA in the Web PKI, because after all it does operate a whole shitload of web sites, and it has secure buildings and trustworthy employees needed to run the CA. Like some other government-owned CAs it has offered up front to limit its CA to a TLD it controls anyway (in this case gov) so it won't be offering certificates to the general public.
They don't have a formal proposal yet, such proposals take anywhere from 6-18 months to process once they come out, and so the IRS or Veterans Affairs won't be getting new certificates from them in 2017, but in 2018 that's definitely a possibility.
Of course, a US Federal Government CA in the Web PKI would be problematic for Google, Apple, Microsoft or Mozilla (all US corporations) to distrust later if things go wrong, this is doubtless why they ask to limit to one TLD, defusing concerns in advance...
Wouldn't they just do what all browser-version-specific websites have done in the past and have an http landing page with a conditional redirect? User agent is IE6, and you progress to ie6.bankofamerica.com. User agent is Chrome/Firefox, progress to webpage with browser version warning and download link for IE6.
Well, just looking at the Bank of America example, they don't seem to use HSTS in their landing page. How widespread is HSTS? How long is the expiry period typically set for (I would guess a long time?)
Does anyone still use browser bookmarks?
Actually, just thinking about it, it might be even simpler than this. If Bank of America wanted to, couldn't they still host their redirect landing page over SSL with a valid non-Symantec certificate, and then redirect to the ie6.bankofamerica.com page which will continue to use the bad Symantec cert? If switching certs for their web infrastructure was really difficult and they didn't want to do it, they could just build a simple little front-end web server with a valid certificate to redirect people to an IE6 download page or ie6.bankofamerica.com.
This made me cry a little. But on a more serious note, every existing link on the Web is essentially a bookmark, so I don't think we can ignore that when discussing impact. (Though I'm betting all incoming requests could be rerouted more easily than telling your customers to (and how to) install a cert...)
HSTS is currently used by 2.8% of all websites, up from 1.2% this time last year. [1] If people are using Qualys SSL Labs tool to check their "grade", they won't be awarded an A+ grade unless their HSTS max-age is at least 6 months [2], so I'm going to assume the average is somewhere close to that due to how common usage of that tool is.
My grandma still uses browser bookmarks, but I have no none-anecdotal source for this.
BoA could absolutely do all the things you just mentioned, but all of them are more difficult than simply replacing their certificate using Comodo or some other trusted root CA.
BoA could absolutely do all the things you just mentioned, but all of them are more difficult than simply replacing their certificate using Comodo or some other trusted root CA.
That depends on the design of the site and their business policies. I agree though - for any sensible organization switching certs is going to be easier. But if that was really the case here, why were they asking Symantec for special favours?
I suspect it was a joke, but you raise a very important question. Unfortunately, some clients (likely embedded devices) trust only Symantec roots, since that's the CA the website was using at the time the developer slapped together their code.
To which the response will inevitably be "Communication with the bank can't be trusted" and many people will read as "The bank can't be trusted". I think people will quickly come to the conclusion that the stakes are much higher for them if the bank can't be trusted when they have their money there, compared to the browser being too assertive, and will just move their money. Without definitive knowledge or a good understanding of all the intricacies, that's the safe decision.
Banks know this. Like the CA system, the whole banking system only functions because of trust, and in the US that trust is backed by the government. They aren't going to let that erode. Regardless of whether all their back-end certs get updated, their customer facing ones will if needed.
The PR campaign won't be targeting users, it'll be targeting business/site owners. A user might be annoyed that random sites stop working, but the people who operate those sites will see their traffic fall off a cliff.
The only effective solution to stop the pain will be to switch to a new cert as quickly as possible, and that only hurts Symantec, not Google
Yes. You can't just jeopardize a substantial portion of a large company's revenue stream like this and not expect retaliation. Guaranteed that unless the executive team steps in to reverse this, Google has made itself a few powerful enemies.
Google is playing with fire here. I would expect Symantec and other major business who stand to be negatively affected, especially the extremely large ones that Symantec was accommodating by skirting some of the EV rules, will immediately start pushing for regulations around this process. That's the easiest way for large companies to control this kind of thing.
It is workable. This gets brought up every time we have an issue like this. The problem is that existing CA's keep fucking up. But the system is clearly working: bad CA's get excluded.
I think the likely result here is more widespread adoption of LE. The point is that CA's shouldn't be businesses.
Maybe, but in the meantime I can't imagine a scenario where such a direct financial threat to a business isn't vigorously defended by Symantec. I'm not a lawyer, but certainly they must be working to determine if they have a legal basis for seeking an injunction against Google. They could even be building some sort of legal theory based on tortious business interference, contending that Google is doing irreparable harm by trying to come between Symantec and the expectations of its paying customers.
> Or they will ignore Google, continue to create bad certs, and users will start getting instructed by sites that they have to manually add a root certificate in order to use they site, and the entire ecosystem will collapse.
IIRC that's Amazon's answer to 'how should a user install Amazon Prime on Android?' I don't know how successful they've been convincing users to allow installation of untrusted apps (I certainly haven't done it), but … probably more than a few have done it.
Installing apps from other stores on Android is literally a checkbox away - but installing new root certs on computers is considerably harder, or impossible if your computer is locked-down (group policy, etc).
And it's really not the sort of thing your average non-technical user is likely to do - and trust me, having supported these users before, it's likely to go horribly wrong if you try providing steps for them.
Hard to say which is worse, the intentional lying or the fact that Symantec has repeatedly violated the BR's and root store policies despite the appearance of best efforts not to.
Yeah seriously, every time Symantec slips up it seems like their response is some variant of "lol whoops, we didn't know we weren't supposed to issue certificates for entities other than the owner!"
The implementation is open source. You can launch your own ACME server (valuable for testing), and use that. CAs implementing this technology obviously need to go through the same hoop-jumping in order to become trusted, but that's true of any strategy of starting a CA.
The technology is available for any CA, existing or new, to copycat.
And if they don't want to use the open source reference implementation, they can cleanroom an ACME server that works with all the existing clients that work with letsencrypt.
If I'm reading the settings page right, Chrome trusts over 70 certificate issuers right now. Let's Encrypt is just one of those, and only issues a limited set of certificate types.
As I understand it, Chrome (unlike Firefox) does not ship its own root CA store - rather it defers to the root store of the operating system that it's running on. It does however apply some form of blacklist / additional restrictions over what the OS may allow.
I'd be quite happy if LetsEncrypt becomes a significant monopoly - they're following much better practices than many other CAs, they run on open source software and are generally operated in a much more transparent way than other CAs. By using stuff like Certificate Transparency Let's Encrypt makes it so their issuances are publicly auditable - much more than many other CAs are doing these days.
I've often wondered: why is trust in CAs an all-or-nothing proposition (aside from EV certs), and why should my particular browser vendor have all the authority over who I should trust?
For the vast majority of users that's probably just fine, but I would have thought that there'd be a browser or extension or something that allows security-conscious power users more fine-grained control over this by now.
For example, I could subscribe to changes in CA trust levels from every major browser vendor, and if they don't agree my browser could show me a warning with an explanation.
Or I could subscribe to feeds from other entities I trust, like the EFF. Or my security-conscious friends.
Or if I decide I have lower trust in certificates issued by governmental CAs, or CAs in certain regions, I could mark them as lower trust.
> I've often wondered: why is trust in CAs an all-or-nothing proposition (aside from EV certs), and why should my particular browser vendor have all the authority over who I should trust?
It doesn't. You can adjust your root certs in Firefox by going to about:preferences#advanced and clicking on certificates.
But what does partial trust look like? Showing half of the HTML? An eyebrow raised emoji instead of a lock?
I wish CA management was easier to bulk-edit. Show me a table of root CAs with their data, their country of origin, etc., and allow me to filter and enable/disable all based on filters.
Full disable would shut down trust entirely, and get the warnings similar to a self-issued cert.
Reduced trust would have a "not Secure" label or something, like a plain http connection.
"Country of origin" is a really interesting one for precisely the Symantec scenario.
Symantec is a US company right? But the main _problem_ happened at a company called CrossCert, full name Korea Electronic Certification Authority. They're Korean.
So if you decided you don't trust Koreans, Symantec's root looks fine, nothing Korean about that. Except, somewhere Symantec signed a contract with CrossCert saying "OK, we'll issue any certificate you want, so long as you pay us and promise to do all these things". Oh, and then they didn't actually check CrossCert did any of the other things (I think we can assume they checked they got paid...). You don't get to see that contract. It wasn't even prohibited by the rules Symantec had agreed to. If Symantec hadn't been caught issuing bogus certificates as a result you wouldn't even be reading about it.
Useless. On my computer it looks like Firefox is using a font that has a sleuth with a magnifying glass and a hat, while Emacs uses a font that has a silhouette of a guy wearing a trenchcoat.
> Or I could subscribe to feeds from other entities I trust, like the EFF.
How would you validate that the EFF's feed is actually from the EFF? Assuming we're using existing SSL infrastructure, the browser would first need to trust the CA used by the EFF, which means we need an initial set of trusted CAs.
It's not WoT because WoT is supposed to help you know of unknown people are secure (say LE and FSF trusts ABC, it probably means that ABC is reliable), which doesn't work at all
Because the process happens in the public newsgroup mozilla.dev.security.policy anyone with a legitimate interest in the Web PKI can ask questions during incidents like this or indeed during Mozilla's new CA application process.
Some of the questions on that list are mine. I don't remember if representatives from Google or Mozilla explicitly told Symantec they needed to answer my questions, beyond a certain point it's implied that smart questions (and I hope mine are smart) should be answered regardless of who asks them.
Other than Google and Mozilla, major trust stores mostly prefer to conduct their activities in private, so we don't know what (if anything) Symantec were asked by Microsoft, Apple, etc.
If I'm reading the post right, it's stricter than that:
> ...distrusting certificates whose validity period (the difference of notBefore to notAfter) exceeds the specified maximum.
I.e., a certificate valid from 1/2015..1/2019 is distrusted as of Chrome 59.
And the more lax restrictions only apply to certificates that have already been issued. Any one issued after Chrome 61 are held to the highest (9 mo) limit.
> In addition, 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.
I agree with the newly issued certs. The other, that's going to be painful, and a mess to figure out, if you are right.. and that's quite possible that you are. UGH.
EDIT: Update, I'm not sure you are correct, I just downloaded the latest dev release (Version 59.0.3047.0 (Official Build) dev (64-bit)) and it accepts a rapidssl issued(symantec owned) cert valid for 1187 days, which would exceed the 1023 days.
It's also possible it just hasn't made it into the release yet, I'll have to keep like a daily eye on this, and plan to replace much much sooner just in case.
Great company and good people involved in CA/B Forum who advocate on behalf of user security. They'll never pull some of the nonsense the other CA's attempt and I can't recommend them enough.
edit: to add, DigiCert were one of the only CA's to support Google's motion to reduce max cert validity period to 12 months, which didn't pass[0]
DigiCert were also the CA that helped us get Tor onion addresses validated which eventually became a standard
Why not keep `/etc/ssl` inside a volume mounted by each docker container and run letsencrypt outside of docker? Each docker container doesn't need its own instance of letsencrypt; it just needs access to your key.
If you use the DNS auth, its actually not bad: you can securely issue the certs on a different machine and just copy the PEM files to the right place. I used this with Route 53's API and it works quite well and is (in my opinion) superior to having to place files.
You can get a Let's Encrypt certificate manually; you don't have to automate it. There are a few options, including https://gethttpsforfree.com/ by 'diafygi, which involves running some openssl commands and pasting public keys and signatures into the web form (which in turn send API requests to Let's Encrypt). Or you can find or build a client yourself.
The only hard part is you'll have to find a way to prove ownership other than email ownership. But if these are public-facing web servers, implementing a response for the HTTP challenge shouldn't be hard, and as the website points out, you can configure all your servers to send an HTTP redirect for the challenge to some other single URL, which you can configure manually. https://letsencrypt.org/docs/integration-guide/#picking-a-ch...
This process is significantly less painful, especially on renewals, than the traditional certificate renewal process. If you're already planning on spending an hour of someone's time a year to request a renewal, pay for it, click a link in an email, etc., plan on spending 10 minute of someone's time every two months, instead. (And an hour is optimistic based on my experience.)
Your public and private keys don't change, since these are renewals. You're just updating the certificates themselves. And certificates are public data (they're sent in their entirety when you make an HTTPS connection), so you can just put them in a git repo or an S3 bucket or whatever else is convenient for your deploy process.
You think it is the same to setup renewal for Letsencrypt and a vanilla cert, but it's not.
We buy 3 year wildcard certs - Rapidssl was about 80$. From about a month before renewal, they start sending you emails and make sure you don't forget.
Letsencrypt is a good idea for larger setups with dedicated devops. For a start-up, it's the exact same argument as Gitlab vs Github.
Can confirm, Lego on k8s is really pain-free to use. Following the official documentation meant that I was able to have HTTPS running on our Google Cloud load balancer within 30 minutes.
Seconding Digicert. They're expensive, but the most solid and trustworthy option when it comes to "old school" cert providers. EV, Wildcard, code signing.
As others have said, Digicert is good, as is IdenTrust (though neither are cheap). You might also look at HydrantID, which is rooted to QuoVadis, who've been around a good long time.
I switched to DIGICERT when Verisign started buying everyone up (then Symantec bought them). I haven't looked back...except for dev boxes where I can get away with Let's Encrypt.
For business I highly recommend DIGICERT. They are an independent company.
I am not sure what standards apply to companies in this segment, but Comodo has an awful track record imho. Just looking at the Wikipedia article gives me a shill. And those are only the cases where Comodo couldn't deny any wrongdoing or failure.
One of Comodo's registration authorities was breached, but not Comodo themselves. Comodo were able to detect the breach and cut off the compromised RA because they were monitoring what their RAs were doing. Symantec, on the other hand, didn't know that their RAs were mis-validating certificates until I noticed and told them.
(Registration authorities are third parties that perform certificate validation on behalf of the CA. I think Comodo bears some responsibility for delegating validation to an RA that was compromised, but Symantec's conduct has been so much worse in comparison.)
Perhaps it's neat for you, I just found out that our newly issued EV certificate status is being revoked in the next build of Chrome, so our expensive EV certificates may as well be $5 StartSSL certificates.
I imagine that there will be a lot of angry customers asking for refunds from Symantec/Verisign for certificates already issued which no longer conform to the offered product.
I for one find it totally neat that people realize their expensive EV cert was a waste of money. Although that was true before, too. EV certs are a waste of money, the only thing they do is show a green bar. They don't improve security.
EV certificates have the same level of confidentiality and integrity as DV certs, but they have different authentication - specifically, they tie the certificate to a legal entity rather than a domain name.
ie.
https://paypal.com-customerservice.ru
vs
PayPal Inc [US] | https://paypal.com
I run https://certsimple.com. We sell EV certs. But you can verify the above pretty easily by checking out the EV guidelines, the additional requirements that apply only to EV certs (https://cabforum.org/extended-validation/). You can also see the difference with openssl pretty easily:
If a site with an EV cert is being spoofed using a similar-looking domain name and a DV cert, how realistically is the user going to remember that the real site is supposed to have an EV cert? (Besides just maybe remembering it for Paypal in particular.)
See also the Nordea section at https://hsivonen.fi/bank-idp/ . How is a user supposed to form a mental model about multi-server org who don't use EV consistently?
That's a legitimate concern. The bank in the link is harming itself with mixed validation and further issues with mixed content (and yes the banking industry surprisingly bad at crypto - Barclays in the UK has mixed content issues pretty frequently).
There's no simple, single answer here: you can stop validation downgrades is pinning to EV roots but browser UI is also a huge part: mobile Safari, for example, simply uses the validated legal entity as the address and keeps it on screen during the entire session (even when you scroll). Visit https://stripe.com on mobile Safari and you'll see
> _______________Stripe Inc.______________
...persistently on top of the screen throughout the entire session [1]. Other browsers don't show validated identity as effectively though.
[1] Safari should also add a country indicator to distinguish other validated legal entities called 'Stripe, Inc.' in different jurisdictions.
But that overlay just before I started reading your landing text is a serious mood-killer. I'm not going to set-up a remainder for when my certificate expires before I read your page.
Thanks! We're actually about the middle of the road price wise, our main thing is tech: the EV process can be pretty painful, our role is to speed it it up and make it easier. We start checking against government directories in 63 countries prior to payment, use webcrypto in supported browsers to quickly generate CSRs, make instant-paste openssl / windows scripts to make an ECC or RSA keypair quickly if you prefer to make keys on your own servers, we have a LOT of country specific logic, a meta directory of 'Qualified Independent Information Sources' to handle that part of the EV requirements, we validate in realtime and a bunch of other stuff to save you time and effort - https://certsimple.com/about.
There's cheaper options around, but we only do EV and we're the best at it.
My understanding is that there is no reason why a DV certificate's Subject can't also identify the legal entity. It doesn't authenticate that the key binds to that legal entity (only the domain), but the Subject line can still be at least informative, even if not authenticated.
What makes an EV cert an EV cert is that it contains a Certificate Policies extension. (There are also requirements for the EV to have certain things in the Subject; I'm only saying that they're not necessarily forbidden from the Subject in the DV case.)
That said, many CAs like to overwrite whatever subject you give them with stuff like what's in your example. But you can find examples on the Internet where this doesn't hold, and the Subject contains useful information (e.g., Wikipedia, Let's Encrypt, Google).
One of the things I wish that x.509 was would be that certificates could have been simply a signed (CSR + additional data from CA); since CSRs are themselves signed, this would have prevented the CA from being able to change the CSR after it's submission; that is, the process of submitting the CSR would give the CA two options: append information and sign, or not sign. As it is, their first option is "rewrite the cert however we like and sign"
It doesn't matter so much for the Subject, but CAs will also do things like take a requested extension that has the critical bit set in the CSR, and mark it as non-critical in the certificate. (or even flat out drop the extension) A dev who blindly assumes that the CA will either do as asked, or refuse with a reason then runs the risk of putting a certificate that was really ever requested into production.
(One, I suppose, could assert that allowing free-form Subjects might cause a CA to sign a cert whose Subject is lying or misleading, which could be bad if the reader thinks the signature implies validation of that data.)
Take a look at Baseline Requirements section 3.2. CAs have to have a basis to believe the subject information they include in the cert, although of course EV requirements are more stringent. E.g.
> If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant’s address of existence or operation.
Absolutely, I totally get that, it's worth mentioning that we take our TLS implementation seriously (HSTS, no TLS1.0, etc) and score an A+ on SSLLabs test: http://i.imgur.com/QbH4YZS.png
The green bar with our company name in it translated in to a measurable conversion increase week for week from guest checkouts, so saying it's a waste of money isn't strictly true in our case.
As the neighbor comment points out, EV validation is absolutely not a waste of money. I've been part of A/B testing on most aspects of domain security and it's arguably one of the best ROIs out there for e-commerce sites.
It proves (if the issuer has done their job) that the organisation requesting the certificate has been properly vetted, so you’re more likely to be doing business with the right website.
What? Of course they improve security. They reduce the risk the user has accidentally navigated to a squatted typo-domain registered by an attacker (or the correct domain, but the registration somehow accidentally expired and was reregistered by an attacker)
They can improve security. We used to pin the EV roots of a couple CAs that we trusted in our mobile apps and in the browser via hpkp. This protected against someone tricking or coercing a lesser CA into issuing a DV cert and MITMing us.
Why does EV make a difference here? Can't you pin an intermediate or root cert from your CA of choice and avoid other CAs issuing end certs for your domain just as well?
I think the idea here is that they're not trying to prevent other CAs from issuing end certs, they're trying to only allow certs for their domain - from any CA on their short list - if the owner of the cert has been through Extended Validation.
Of course, this only works if the CA _actually_ makes sure they don't use the root you pinned for DV issuance. Just because it says "Ultra Great EV root" in the CN doesn't provide you that security, and it won't count as mis-issuance so long as the DV certificate doesn't have an EV policy OID baked into it.
If we'd asked in 2015, Symantec would probably have pointed us to CrossCert's CPS which said they only use certain Symantec roots. In fact Symantec had no mechanism in place enforcing that, CrossCert could and did issue from any Symantec root, whether it was on the list or not. So, if you chose a root thinking "I don't trust CrossCert, but they don't use this root so it's fine", oops, too bad.
If we had a DV cert and pinned the DV root then the barrier for an attacker is a lot lower. They just need to jack our DNS and get their own automated DV cert issued quick.
I would contact your hosting provider. They are going to have to find a new CA themselves and when they do, I would guess they would be willing to mint you a new EV cert.
Good. The security of certificate system is dependent on an incentive model where misbehavior is punished with revocation. It is important not just because we shouldn't give individual authorities trust after they have demonstrated themselves untrustworthy (although that is an important factor), but also as a punitive measure to disincentive misbehavior.
I don't think that's the case here, I think Symantec understood perfectly but thought they were too big to get anything more than a slap on the wrist from Chrome. Chrome's previous sanctions on Symantec, though very helpful for those trying to evaluate Symantec and inconvenient to implement on Symantec's side, were not much of a threat to their business.
Google's also been looking to limit the maximum validity lifetimes in general through the CA/B Forum[1] in a ballot that ended up not passing (with hints[2] that Chrome would end up enforcing something similar itself even if it wasn't part of the Baseline Requirements).
This seems to be indicative of the general indication that Chrome wants to head in anyway[3].
"Baseline Requirements" sort of implies that what is specified is minimum, rather than exhaustive, rules, and that specific applications will have additional rules.
Mozilla's rules are public so you can go read them, and indeed you can help write them. But most famously they required all CAs to disclose loads of stuff, and they require CAs to do lots of stuff in public where everybody can see it, not behind closed doors where we don't know what they're up to.
Google's rules include lots of stuff about their Certificate Transparency idea, which has helped no end.
Microsoft's rules famously include them getting a veto where they can order any CA to revoke a certificate or else leave their trust programme. They mostly use this to zap malware / phishing sites.
Apple's rules forbid having lots of roots at once. Although apparently this didn't apply to Symantec, or various other people. Huh.
The standards group in question is unfortunately impotent. Two totally reliable voting blocs: the browsers and the CAs. There are more CAs than browsers, so the result of every vote is in the favour of the CAs.
As was noted above, they have a constituency representation system so ballots have to pass with support from both constituencies, rather than an absolute majority of members.
> Kinda undermines the idea of having a standards group if Google is going to strongarm the industry by doing their own thing anyways
In any industry where a single actor has a clear majority of the market share, you either vote with your feet (and implore all your friends to do so as well) to bring the powers back into equilibrium, or you cross your fingers and pray that Goliath is (and remains) benevolent.
Symantec thinks Google is being inflammatory. Symantec fired the people who made the test cert a couple of years ago.
Here's Symantec's press release:
Google’s statements about our issuance practices and the scope of our past mis-issuances are exaggerated and misleading. For example, Google’s claim that we have mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates – not 30,000 – were identified as mis-issued, and they resulted in no consumer harm. We have taken extensive remediation measures to correct this situation, immediately terminated the involved partner’s appointment as a registration authority (RA), and in a move to strengthen the trust of Symantec-issued SSL/TLS certificates, announced the discontinuation of our RA program. This control enhancement is an important move that other public certificate authorities (CAs) have not yet followed.
The 30 000 certificates don't have any documentation. The BRs require that a CA keeps documentation showing how they validated the Subject, because without that any CA could issue anything and then say "Er, I forget why, but it was definitely OK" and who can prove they were wrong?
CrossCert wasn't able to produce any documentation for the certificates they got Symantec to issue. Maybe their dog ate it, or they kept it in the Recycle Bin on somebody's laptop and then mistakenly hit "Empty" one day. Most likely they simply never created the documentation at all, because Symantec had never asked them to produce it, so why bother?
But that means we have no reason, other than a general sense that CrossCert appear to have been incompetent rather than malevolent, to believe any of those certificates was actually validated. On that basis they're mis-issued, and so Symantec revoked them.
The 127 certificates discovered by investigators are clearly bogus, some aren't even for valid domain names, but the thousands of others weren't magically fine - we have no idea, and not having any idea is itself unacceptable.
It is true that Symantec shut down their entire RA partner programme (the relationship with CrossCert and half a dozen others) without explicitly being told to do that, and personally I felt that might be enough, but Google clearly don't see it the same way.
Not much focus in the comments has been put on the 9-month certificate validity, but it seems like that is going to be almost as big a punishment for Symantec as the deprecation. Because dealing with SSL is so painful for some large corporates, being told that you have to go from a 3 year renewal schedule to a 9 month one would be enough to cause many to go looking elsewhere.
Since certificate revocation is pretty much unworkable, reducing the maximum lifetime of certificates is probably a good thing for security in general.
SYMC is at an all time high, and every one of their EV certificate customers is about to start talking to different security vendors. The Jan18, Jan19 near ATM puts are quite reasonably priced.
They'll all be caught by surprise and lose their shirts when Symantec releases their financials next quarter and the stock tanks. The market is full of ignorant people.
Usually I agree, but SYMC is at an all time high and trading at 40x price per earnings. The price already implies a massive bet on increased profits, but there is no way that is going to happen.
It's better than it used to be. We have 4 major browser vendors now, Apple (Safari and iOS), Microsoft, Google (Chrome and Android), and Mozilla, all of which have plenty of market share and none of which have most of it.
There was a long period of many years when IE was king and anything else was irrelevant. There was also, even earlier than that, a period where Mosaic/Netscape/Mozilla and its kin were dominant.
This is the best it's been in a long time in terms of no single browser maker controlling the market.
Indeed, there was a set of roots IE 5.01/NT4 SP6/Win2000 and later trusted, and at that time only XP did automatic root cert update making them very valuable. Just before then, I think IE/SChannel only trusted VeriSign/Thawte/CyberTrust, and VeriSign bought Thawte just after IE 5.01 and NT4 SP6 was released.
It will be interesting to see what happens when a Chrome user can't access his bank web site because of this, and the bank tells her to switch to Firefox/IE/Safari.
As someone who just renewed a Symantec EV cert (for a pretty penny), this would super piss me off.
The steps Google has laid out seem proportionate to me. It clearly gets the message across without unduly burdening 3rd parties like me.
And it has nudged me to look at other CAs. Unfortunately the first good option I've looked at--Digicert--has also been publicly rapped on the knuckles by Ryan Sleevi this month.
Some Symantec customers are in a position to file a complaint with Google well over the heads of the Chrome cert team. Some have many $millions of transactions dependent on Symantec certs, and aggressive legal staff.
Imagine if Chrome started reporting all Apple and Microsoft domains as insecure, with no warning. That's straying into very deep waters.
To be clear: I support Google's action against Symantec, and it is causing me to look at other CAs. But I need time to make an orderly change.
It's not tortious interference with Symantec's business (who are still "free" to issue whatever they like).
Google is under no obligation and cannot or should not be coerced into saying "You have to accept Vendor A's CA so that they can continue to represent Vendor B's SSL certificate as 'secure'."
That's also very deep water that might result in some 'diplomacy' but with little actual legal position.
You can't compare Symantec with Apple and MS, since Apple and MS are competent.
If you think someone might sue Google, on what basis? And Google is more than capable of defending itself.
I agree about the time needed to make an orderly change, which is why I didn't propose that connections fail yet, only that they not be presented as secure in the UI.
Apple and Microsoft buy their TLS certs from Symantec. All their sites would be affected if Chrome abruptly stopped trusting Symantec certs overnight.
Imagine if everyone going to Apple.com in Chrome suddenly saw "site insecure" when they were trying to buy an iPhone--an area where Google is a direct competitor.
They're not bigger than Google. And it's Google's browser and the open source Chromium project, so I'm having a hard time seeing how Symantec is going to get a judge to say anything along the lines of "I forbid any and all members of the Chromium project to commit anything to the codebase that would no longer treat Symantec issued certificates as before". Especially considering since plenty aren't under US jurisdiction nor necessarily employed by Google.
Then they'd also have to strong arm Mozilla, Apple and Microsoft since they're rather likely to act too and at least the latter two don't disclose such changes until they've made them.
But, Symantec has generally shown little/no morals in past times when it comes to attempting to protect their business interests. Not really seeing why this would be different. :/
TL;DR: in 2016 Symantec issued unauthorized certs for example.com (owned by ICANN) and a multi-domain cert with SANs for test1.com, test2.com, test3.com... even though those domains are each owned by very different organizations and did not all agree to have a common cert.
It's more than that. The ensuing thread uncovered that Symantec had exercised very lacking oversight over their partners (called Registration Authorities, or RAs) who were allowed to perform certificate validation on Symantec's behalf.
As far as I can tell, discussion about what to do with Symantec was ongoing, Google didn't think the outcome was going to be what they wanted, and then enacted a different policy on their own.
I was wondering the same thing. In previous cases, it seemed that Mozilla and Google acted as one, by working off the same NSS trust database. Has something about that changed? Apparently Google thinks Mozilla is moving to slow on this one?
We need a service to check if your certs could be flagged as bad. Especially since this spans so many brands (Symantec, Equifax, VeriSign, GeoTrust, Thawte, etc). Something like, plug in the domain name, and it'll tell you if you need to update the cert.
Equifax
VeriSign
TC TrustCenter GmbH
RSA Data Security
Equifax Secure
Symantec Corporation
GeoTrust Inc.
Thawte Consulting cc
thawte
Thawte Consulting
Equifax Secure Inc.
TC TrustCenter for Security in Data Networks GmbH
The USERTRUST Network
Thawte
I do not know how to observe if this has been accepted, does it not require 3 others to approve and say 'looks good to me' to continue with this proposal?
TLDR: Look at the IdenTrust numbers if you want to know the real Let's Encrypt numbers.
Not many people use Let's Encrypt's own root for their validation chain when they use Let's Encrypt certificates. The Let's Encrypt root is not propagated widely enough across clients.
We (Let's Encrypt) have a cross-signature from IdenTrust, that's what most people use because it's widely trusted. IdenTrust issuance is otherwise very small, so you can effectively consider the IdenTrust numbers in charts like this to be a proxy for Let's Encrypt.
W³Techs also understates the fraction of "web sites" that use LE certs because it counts only the 10,000,000 top sites. But LE alone has current valid issuance covering over 30,000,000 subject names, most of which are small sites not in the top 10,000,000 sites by traffic volume or search engine ranking.
Judging by the explosive growth of IdenTrust, which cross-signs Let's Encrypt's certs, I'd guess that Let's Encrypt certs are being counted under IdenTrust.
> Combined with the gradual move to certificates with shorter lifespans anyway (as a way of coping with problems like this, and with the difficulty of certificate revocation generally), automation is a necessity going forward.
Interesting. What are the effects of automation? E.g. is it possible to automate the update of EV certs? Is this opinion fueled by the idea that websites should be hosted in the public cloud? What is OWASP's stance?
Where can I find more on pro & con automated cert renewal? Around the time when Letsencrypt was introduced, there must have been someone who wrote an informed article/blog on automated cert renewal.
What is the chrome release schedule? i.e. what is the timeline for the 59 - 64 releases to happen? A quick google isn't getting me an answer(and I don't use Chrome, so don't really pay attention).
Unless Mozilla and IE goe along with this, effected orgs could just inform users that Chrome is not a supported browser? Have we heard from the other browser vendors?
Let's be honest, switching your cert is a far cheaper option than the lost business of telling 50% of your users that they need to switch browsers.
Whith ecommerce sites being so hyper focused on abandoned cart stats, this is the easiest change they'll make all year.
For ecommerce yes, but the people most impact here are prob. banks... and if somones back tells them they have to install and use FF or use Edge over Chrome, they will probably do it.
"We now do not support the one browser that has over 50% of usershare." To me, that seems to be the equivalent of shooting yourself in the foot...using the Tsar Bomba.
Byng's execution is referred to in Voltaire's novel Candide with the line "Dans ce pays-ci, il est bon de tuer de temps en temps un amiral pour encourager les autres" – "In this country, it is wise to kill an admiral from time to time to encourage the others."[1]
Why trust central CA who say security charge for it but do not implement it? Why not instead use a distributed security model such as LetsEncrypt and Blockchain?
The whole security model of the web is quite centralized maybe we need something more distributed? What if you had strong hashing on content, distributed webservers and distributed content?
I'd be very surprised if Symantec doesn't have some backroom deal with intelligence agencies, and not just in the U.S. either, especially since they've acquired BlueCoat - a "security company" known for selling surveillance tools to authoritarian regimes - and after they made the BlueCoat CEO the CEO of Symantec.
Interesting that it would be "so much easier" for the U.S. intelligence community to steal most certificates or work around TLS, when countries like Thailand, which have much fewer resources, prefer to get Microsoft to install their own root certificate for them in Windows. Perhaps this is what the IC meant as well, when it said there are other easier ways? Why bother with Verisign's solution, when they could have their own root certs in Windows?
TL;DR Google prefers to override what the standards say about validity of certicates instead of what would be the logical thing: stop trusting Symantec root Certs. A dangerous precedent.
Google is divesting trust from Symantec but is doing it in a way that avoids hurting end-users and badly breaking the internet. They explicitly state why they don't just want to revoke it in one go and they have really decent arguments. What are yours?
Aside from that, to the best of my knowledge the CA/B forum doesn't set forth any rules that require the immediate and complete removal of trust of a CA that is found to be in violation of the guidelines. I also don't see how they could, the best they could do is put out some form of recommendation but it's up to the parties that actually include the CAs to decide how they get removed, which is normally stipulated in the rules for inclusion in a Root Certificate bundle.
That's unlikely, as they currently do not offer certificates to the general public. I imagine if they do at some point, it might be as part of something like their version of Amazon's ACM for their Cloud offerings, or for custom domains on sites like Blogger. I'd expect both to be free. They're also a platinum sponsor of Let's Encrypt.
Google and Mozilla were heavy sponsors of LetsEncrypt (in money and in Mozilla's case manpower too) because they wanted to push out HTTPS more, and mandate HTTPS for some new HTML features. That would have been problematic if certificates weren't free or convenient.
In Mozilla's case, HTTPS is better for privacy. In Google's case, HTTPS makes it harder to substitude their ads.
The schedule they're proposing tries to specifically avoid as much of this as possible. This is probably as close to "no impact for average users" as you can get if you don't want to accept that too-big-to-fail is a thing in the Web PKI.
They propose a gradual distrust of existing certificates by reducing the 'maximum age' of the certificates with each release of Chrome.
EV certificates are proposed to have their EV indicators stripped immediately until Symantec, for one year, demonstrates sustained compliance.