
Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates - ehPReth
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ
======
stevecalifornia
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.

~~~
DaiPlusPlus
They're also planning on stripping EV status from their Certs too... that's
going to be fun for a lot of banks.

~~~
dmix
Banks can just switch to better SSL services...

~~~
ygjb
ha.ha.ha.

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? :/)

~~~
Sir_Substance
>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.

~~~
DaiPlusPlus
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)

~~~
pauldino
So basically you're pinning the server certificate chain into your signed
client code? Actually that sounds like a good thing!

[https://www.owasp.org/index.php/Certificate_and_Public_Key_P...](https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning)

~~~
ygjb
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 :)

------
jwarren
If anyone here hasn't realised, Symantec bought Verisign back in 2010 - who
own many brand names, like GeoTrust, Equifax, Thawte etc. You can see a list
of their roots certs here:
[https://chromium.googlesource.com/chromium/src/+/master/net/...](https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec)

In case you missed it at the bottom:

> From Mozilla Firefox’s Telemetry, we know that Symantec issued certificates
> are responsible for 42% of certificate validations

~~~
Minikloon
Symantec bought Verisign's authentication business, still two different
companies.

GeoTrust was started from buying Equifax's security business. Symantec bought
GeoTrust. Symantec doesn't own the Equifax brand or company.

------
NateyJay
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.

[1]
[https://w3techs.com/technologies/history_overview/ssl_certif...](https://w3techs.com/technologies/history_overview/ssl_certificate)

~~~
ChuckMcM
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.

~~~
makmanalp
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.

~~~
jasode
_> 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.)

[1]
[https://www.google.com/search?q=google+chrome+this+site%27s+...](https://www.google.com/search?q=google+chrome+this+site%27s+security+certificate+is+not+trusted&source=lnms&tbm=isch)

~~~
ergothus
or

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.

~~~
jasode
_> 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?

~~~
gcp
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).

~~~
jasode
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.

~~~
gcp
I believe it is actually a matter of political campaigning in South Korea to
get rid of ancient IE ActiveX requirements for government websites.

~~~
rspeer
It's not just government websites, it's requirements that the government
placed on _all_ e-commerce sites in South Korea.

------
tlrobinson
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.

Basically a web of trust for CAs.

~~~
jldugger
> 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?

~~~
unethical_ban
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.

~~~
tialaramex
"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.

------
thenickdude
It looks like the questions that Google/Mozilla asked Symantec and didn't like
the answers to are posted here:

[https://knowledge.symantec.com/support/ssl-certificates-
supp...](https://knowledge.symantec.com/support/ssl-certificates-
support/index?page=content&id=INFO4154)

(Archive link: [http://archive.is/Cq9VO](http://archive.is/Cq9VO) )

Really interesting reading!

~~~
tialaramex
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.

------
zie
I was curious if this would affect my Symantec issued certs... according to my
date math:

Chrome 59 (Apr 13, 2017) +1023 days: 2020-01-31

Chrome 60 (May 25th, 2017) +837 days: 2019-09-09

Chrome 61 (Jul 20th, 2017) +651 days: 2019-05-02

Chrome 62 (Aug 31st, 2017) +465 days: 2018-12-09

Chrome 63 (Oct 12th, 2017) +279 days: 2018-07-18

~~~
jstrom
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.

~~~
zie
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.

~~~
hsivonen
> It's also possible it just hasn't made it into the release yet,

The proposal was just made, so you shouldn't expect it to be reflected in code
just yet.

------
sandGorgon
> _All Symantec issued certificates. GeoTrust and Thawte are CAs operated by
> Symantec, simply afforded different branding.

>While this list may need to be updated for some recently created roots,
[https://chromium.googlesource.com/chromium/src/+/master/net/...](https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md)
may accurately capture the state of impact_

Damn. There goes my certificate (Rapidssl). Anybody know what are the
remaining, trustworthy certificate issuers ?

No we cannot use LetsEncrypt for convenience reasons (we bake our certificate
pub key in many places)

~~~
mastax
I have heard lots of good things about Digicert, FWIW. No personal experience
as my use case can be covered by LetsEncrypt.

~~~
protomyth
Digicert works for us. Wouldn't mind switching to LetsEncrypt but vendors are
the issue (oh, the joy of approved lists).

------
musicnarcoman
> Intent to Deprecate and Remove: Trust in Existing Symantec-Issued
> Certificates

When I read that something like this popped up in my head:

"Google is using the nuclear option on Symantec. Neat!"

~~~
Shanea93
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.

~~~
hannob
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.

~~~
nailer
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](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/](https://cabforum.org/extended-
validation/)). You can also see the difference with openssl pretty easily:

Here is a DV cert:

    
    
        openssl x509 -in domain-validated-example.com.crt -noout -text | grep Subject
         OU=Domain Control Validated
         CN=example.com
         DNS:example.com
    

Here is an EV cert:

    
    
        openssl x509 -in extended-validated-example.com.crt -noout -text | grep Subject:
           jurisdictionOfIncorporationCountryName=GB
           businessCategory=Private Organization
           serialNumber=09378892
           C=GB
           ST=City of London
           L=London
           O=example Limited
           CN=example.com
           DNS:example.com -

~~~
hsivonen
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/](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?

~~~
nailer
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](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.

------
benchaney
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.

------
TenOhms
It amazes me how often Symantec is in the news about the same subject, yet
they seem to be incapable of learning a lesson from it.

~~~
abraae
As they say "It is difficult to get a man to understand something, when his
salary depends upon his not understanding it."

~~~
johncolanduoni
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.

------
lukegb
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].

[1]
[https://cabforum.org/pipermail/public/2017-January/009373.ht...](https://cabforum.org/pipermail/public/2017-January/009373.html)

[2]
[https://cabforum.org/pipermail/public/2017-February/009746.h...](https://cabforum.org/pipermail/public/2017-February/009746.html)
\- there was a more explicit post elsewhere but I can't find it in the
archives right now

[3]
[https://twitter.com/sleevi_/status/829804370900426752](https://twitter.com/sleevi_/status/829804370900426752)

~~~
zokier
> with hints[2] that Chrome would end up enforcing something similar itself
> even if it wasn't part of the Baseline Requirements

Kinda undermines the idea of having a standards group if Google is going to
strongarm the industry by doing their own thing anyways

~~~
dragonwriter
"Baseline Requirements" sort of implies that what is specified is minimum,
rather than exhaustive, rules, and that specific applications will have
additional rules.

~~~
tialaramex
And they all do.

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.

------
WillyOnWheels
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.

~~~
tialaramex
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.

------
dantiberian
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.

~~~
thenickdude
Since certificate revocation is pretty much unworkable, reducing the maximum
lifetime of certificates is probably a good thing for security in general.

------
unabridged
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.

~~~
phonon
Crazy! A third of SYMC's revenue might be going POOF! and the market is just
shrugging?

~~~
beedogs
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.

~~~
NickNameNick
Just remember that the market can afford to be wrong longer than you can
afford to bet against it.

~~~
unabridged
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.

------
praptak
It's a bit scary how much power do browser creators wield. Even if it's being
used for good.

~~~
galdosdi
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.

~~~
yuhong
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.

------
marina8888
Related: not valid certs should show a red warning after accepting them:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1349897](https://bugzilla.mozilla.org/show_bug.cgi?id=1349897)

is this for all the certs or just symantec certs?

------
kartickv
Why not immediately begin treating these connections as plain HTTP? Don't show
the padlock or "Secure".

Don't fail the connection, so people will still be able to use the site, but
don't present it as secure.

This would be a stronger action than treating EV certs as non-EV, which only a
few geeks will notice. Or reducing the maximum age of certificates.

~~~
nikanj
And teach your grandpa it's ok if his bank's website no longer displays that
green address bar?

~~~
kartickv
Making your grandpa think everything is right with the bank defeats the whole
point of what Google is trying to do.

------
justinclift
Symantec being well... Symantec, I'd expecting them to lawyer up in order to
delay, or outright block this.

They're big enough to afford the higher end law firms likely needed too. :(

~~~
daenney
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.

~~~
justinclift
Sure, it'd probably be an uphill battle.

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. :/

------
Ajedi32
Anyone have any more information on the incidents that triggered this
response? I was able to find this article on Google's Security Blog:
[https://security.googleblog.com/2015/10/sustaining-
digital-c...](https://security.googleblog.com/2015/10/sustaining-digital-
certificate-security.html)

But that's almost 2 years old. Have there been any more recent incidents that
I'm unaware of?

~~~
agwa
[https://www.mail-archive.com/dev-security-
policy@lists.mozil...](https://www.mail-archive.com/dev-security-
policy@lists.mozilla.org/msg05455.html)

~~~
pilom
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.

~~~
agwa
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.

~~~
caf
...and at least one of those RAs didn't seem to be doing any validation at
all!

------
Animats
What's Mozilla doing?

~~~
gcp
[https://groups.google.com/forum/#!topic/mozilla.dev.security...](https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/kxs3kyqRqYU)

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.

------
WestCoastJustin
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.

~~~
thenickdude
Since Google typically enacts the restricts through major Chrome updates,
running the Beta version of Chrome can give you some early warning at least.

------
shkkmo
Is there a list anywhere of which EV cert providers use Symantec as a CA?

~~~
revelation
From the Google link on Symantec root certs:

[http://pastebin.com/raw/nUEq5cFP](http://pastebin.com/raw/nUEq5cFP)

Not sure if all of them issue EV.

~~~
jwarren
I extracted a readable list of cert providers:

    
    
      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
    

Source here in case I screwed up or anyone wants to verify my terrible regex:
[https://gist.github.com/JodiWarren/376aebbf7ce6902b06766843f...](https://gist.github.com/JodiWarren/376aebbf7ce6902b06766843f4d44dc7)

------
fosco
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?

sorry if I missed this...

------
marina8888
But why is
[https://w3techs.com/technologies/history_overview/ssl_certif...](https://w3techs.com/technologies/history_overview/ssl_certificate)
saying Let’s Encrypt has 0.1% when
[https://letsencrypt.org/stats/](https://letsencrypt.org/stats/) says 32
million Fully-Qualified Domains Active?

32 million = 0.1% 32 000 million SSL certs? = 100%

? what?

~~~
jaas
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.

-Josh from Let's Encrypt

~~~
schoen
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.

[https://w3techs.com/technologies](https://w3techs.com/technologies)

[https://letsencrypt.org/stats/](https://letsencrypt.org/stats/)

------
smartbit
in _chris palmer_ mar 23, 19:33 (9th answer)

> _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_.

------
gigatexal
I'd rather trust Google to be a/the defacto CA than some has been AV company.

------
zie
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).

~~~
prdonahue
What'd you search for? I typed in: chrome release schedule

and this was the first link:
[https://www.chromium.org/developers/calendar](https://www.chromium.org/developers/calendar).

~~~
zie
Thanks! My date math says:

Chrome 59 (Apr 13, 2017) certs invalid after 2020-01-31

Chrome 60 (May 25th, 2017) certs invalid after 2019-09-09

Chrome 61 (Jul 20th, 2017) certs invalid after 2019-05-02

Chrome 62 (Aug 31st, 2017) certs invalid after 2018-12-09

Chrome 63 (Oct 12th, 2017) certs invalid after 2018-07-18

------
bandrami
PKI is broken. The problem isn't the crypto, it's the wardens.

------
voidlogic
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?

~~~
TOMDM
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.

~~~
voidlogic
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.

------
hughw
"...pour encourager les autres"

~~~
lucb1e
In English please?

~~~
hughw
_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]

[1]
[https://en.wikipedia.org/wiki/Battle_of_Minorca_(1756)](https://en.wikipedia.org/wiki/Battle_of_Minorca_\(1756\))

------
acd
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?

------
mtgx
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.

~~~
dsl
Prior to the Symantec aquisition, VeriSign used to pitch just this thing as a
product. AFAIK the usage was limited to DoD and a few mundane things.

The IC wasn't interested because it was easier for them to just steal
certificates or work around TLS completely.

~~~
mtgx
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?

The CA system is such an untrustworthy mess.

[http://www.theverge.com/2017/1/25/14381174/microsoft-
thailan...](http://www.theverge.com/2017/1/25/14381174/microsoft-thailand-
government-surveillance-thai-censorship-encryption)

~~~
dsl
Because using your own CA is not deniable. You aren't allowed to move forward
with any solution that may lead to attribution.

------
jwildeboer
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.

~~~
daenney
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.

------
wasntme
Are they just hoping to drive business to their new CA: Google Trust Services?

~~~
pfg
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.

~~~
ourcat
This happened recently with all my free StartSSL / Startcom certificates. I
switched to LetsEncrypt. Also noticing Google and Mozilla's sponsorship.

~~~
gcp
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.

------
nikanj
TLDR: for the next few months, expect to tell your relatives "just click yes
on the big red warning dialog". Not sure if this is good conditioning.

~~~
pfg
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.

