Chrome canary (66) blocks symantec issued SSL certificates | Hacker News Reader

Chrome canary (66) blocks symantec issued SSL certificates

twitter.com

58 pointsvvoyer12 comments

Background: https://security.googleblog.com/2015/10/sustaining-digital-c...

That is a previous Symantec incident from 2015. It certainly adds to the history of issues they've had, but Google announced their plans to distrust Symantec in this more recent blog post, in response to a series of misissued certificates that came to light in January 2017:

https://security.googleblog.com/2017/09/chromes-plan-to-dist...

After Google published that post, Symantec responded with their own open letter objecting to Google here:

https://www.symantec.com/connect/blogs/symantec-backs-its-ca

However they subsequently relented, and decided to sell their PKI business to Digicert rather than rebuild it as would be necessary to regain browser trust.

Anyone out there with Chrome Canary verify the claims?

I run Linux and unfortunately Google hasn't seen fit to grace us with access to Canary on this platform.

Warnings have been thrown on recent Chrome versions to console about this for a while now

Where? I went to https://www.symantec.com/ in Chrome Stable 63.0.3239.140 and didn't see any entries in the dev console about the CA being untrusted or anything like that.

EDIT: I'm an idiot, it didn't occur to me that Symantec didn't sign their own cert. But they don't, it's from DigiCert. Can anyone link to a site that uses Symantec certs?

https://static.ctctcdn.com/

Console throws up this warning about M70 though.

> The SSL certificate used to load resources from https://static.ctctcdn.com will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.

FYI This other comment: https://news.ycombinator.com/item?id=16300104

Says Symantec sold their cert business to DigiCert

So could it be a cert that was issued as Symantec and just now shows as DigiCert and would still give you the error?

you can open up your regular Chrome dev tools and look at the console for the warning. Any site with the warning raises the error in 66.

Are you aware of the trunk builds of Chromium?

https://download-chromium.appspot.com/?platform=Linux_x64&ty...

I deeply appreciate that's not "Chrome," nor Canary, but wanted to offer it in case you weren't previously aware

I wasn't, thanks!

Peronally I lost faith in browser makers ability to determine trust along time ago. Validate on first use and peer verified checksums of certs is a much better idea imho. Works for ssh. Where security matters, bank, logins, etc one click to validate an md5 sum against a hash on the webpage itself would be better than Google tring to police who has had their web server hacked.

If you visit a few different ssh hosts in a week, and just a few new hosts each month, then trusting the host cert manually is feasible (but who actually verifies).

But it's easy in a short browsing session for your User Agent to connect to hundreds of machines over TLS. Manually verifying them all is not feasible. And verify against what? A webpage? How is that validated.

TLS and X.509 certs have their flaws, but ssh style trust is not the solution.

The problem is: if your browser adds a CA to it's trust root, it can issue (and thus your browser trusts) any site on the internet.

I would rather that if I visit https://www.police.uk then the certificate is issued by a CA that specifically allowed to issue .uk domain certs.

Currently my system trusts "Belguim Root CA2" and "Amazon Root CA 1". Should they be able to sign certs for the .ca or .edu domains?

Do I trust Amazon enough to not issue certs for their competitors?

Reply on news.ycombinator.com