Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome's Plan to Distrust Symantec Certificates

security.googleblog.com

Post reply on HN
Print view View original

51–60 of 207 posts

Re: Chrome's Plan to Distrust Symantec Certificates

#51

Post by cbhl »

JoeMalt wrote: post #22
dsp1234 wrote: post #3

"including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL" RIP RapidSSL wildcard

Wow, I never realised VeriSign was a Symantec brand. I'm not sure what it says that Google doesn't trust the company that operates the registry for .com

Operating a domain registry and issuing EV certificates require different levels of trust.

Don't read too much into Alphabet/Google using other gTLDs instead of .com, like https://abc.xyz or https://blog.google -- that's separate work done by separate people on a separate team.

Re: Chrome's Plan to Distrust Symantec Certificates

#52

Post by antihero »

What are some trustable providers of EV certificates? LetsEncrypt is wonderful, but if I'm a company that needs to show the company name next to the padlock, who should I be using? What's an easy way to check if a provider (for instance Gandi, who I use for my domains) is going to be culled by this?

In fact, I don't even seem to able to find certificate information in Chrome any more - clicking on the padlock just gives me a bunch of settings and "Learn more" which is some annoying page.

Edit: It's in Developer Tools under "Security"

Re: Chrome's Plan to Distrust Symantec Certificates

#53

Post by lawnchair_larry »

cperciva wrote: post #20
dragonwriter wrote: post #17

Earlier quoted context omitted.

“distrust” is an established English words that means exactly what Google intends. “detrust” is, while not hard to figure out, an unnecessary neologism.

But "distrust" doesn't convey the full meaning. They're not talking about merely not trusting Symantec certificates; they're talking about removing existing trust in the certificates.

untrust?

Re: Chrome's Plan to Distrust Symantec Certificates

#54

Post by CydeWeys »

cbhl wrote: post #51
JoeMalt wrote: post #22

Earlier quoted context omitted.

Wow, I never realised VeriSign was a Symantec brand. I'm not sure what it says that Google doesn't trust the company that operates the registry for .com

Operating a domain registry and issuing EV certificates require different levels of trust. Don't read too much into Alphabet/Google using other gTLDs instead of .com, like https://abc.xyz or https://blog.google -- that's separate work done by separate people on a separate team.

We are in contact, though. Don't read too little into it either ;)

Re: Chrome's Plan to Distrust Symantec Certificates

#56

Post by pfg »

rand_r wrote: post #41

Amusing that security.googleblog.com itself is using a TLS certificate ultimately signed by GeoTrust Inc, which is owned by Symantec.

Fun fact: one of the "independently-operated and audited subordinate CAs" that is exempt from this is, yep, you guessed it, Google. They've recently acquired a GlobalSign root and are in the process of getting their own roots added to trust stores, but I imagine they'll want to keep chaining back to the widely-trusted GeoTrust root for a few more years.

(IIRC Apple is on that exception list too.)

Re: Chrome's Plan to Distrust Symantec Certificates

#57

Post by peterwwillis »

pfg wrote: post #46
peterwwillis wrote: post #39

Earlier quoted context omitted.

Well I have a problem with the fact that you can't stop random CAs from issuing certs for a domain you own. But I don't think that's changing anytime soon. Passwords provide security for data at rest, a properly hardened server makes it very difficult to dump memory in certain circumstances, and hsm are practically a requirement in some environments. And finally, say I wanted to use LetsEncrypt, but I wanted to manag…

> Another thing is, let's say I use some other CA for my certs, and I don't want LetsEncrypt issuing any. I can't really stop them, can I? You absolutely can. Let's Encrypt was one of the first CAs to support CAA (and, IIRC, they supported it when they first launched). CAA is a DNS record that lets you specify which CAs are permitted to issue certificates for your domain. > And finally, say I wanted to use LetsEncryp…

I wasn't aware of CAA, that's a nice development.

> Do you want the ability to issue certificates under your own (constrained) intermediate certificate?

Look at it this way: currently, if you can send network traffic from some IP space, you can create valid domain certs. This is the equivalent of using a hosts file with a list of IPs to authenticate an ssh connection. Yes, I think an intermediary key, and not simply some arbitrary control of a network, should be required to generate a cert. It seems like CAA, or some extension thereof, could help this become a reality.

Re: Chrome's Plan to Distrust Symantec Certificates

#58

Post by Ajedi32 »

rand_r wrote: post #41

Amusing that security.googleblog.com itself is using a TLS certificate ultimately signed by GeoTrust Inc, which is owned by Symantec.

Actually, that subordinate CA isn't affected. See:

https://chromium.googlesource.com/chromium/src/+/master/net/...

And the blog post states:

> This will affect any certificate chaining to Symantec roots, except for the small number issued by the independently-operated and audited subordinate CAs previously disclosed to Google.

Re: Chrome's Plan to Distrust Symantec Certificates

#59

Post by driverdan »

antihero wrote: post #52

What are some trustable providers of EV certificates? LetsEncrypt is wonderful, but if I'm a company that needs to show the company name next to the padlock, who should I be using? What's an easy way to check if a provider (for instance Gandi, who I use for my domains) is going to be culled by this? In fact, I don't even seem to able to find certificate information in Chrome any more - clicking on the padlock just gi…

> I'm a company that needs to show the company name next to the padlock

Does anyone actually look at or care about that?

Post reply on HN