Live data from Hacker News

Chrome's Plan to Distrust Symantec Certificates

security.googleblog.com

31–40 of 207 posts

Re: Chrome's Plan to Distrust Symantec Certificates

#31

Earlier quoted context omitted.

Not only that, but they're doing things like Certificate Transparency - publishing every certificate they sign into public logs and they're funded and supported by some of the biggest names in online security and privacy. They're probably the most trustworthy CA on the planet.

Considering that literally anyone who gets even local access to any server at all, or can spoof one - even servers that have never used LetsEncrypt before - can generate new valid LetsEncrypt certificates, and nothing generated has a password on it, I don't know if I would consider them trustworthy. If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - an…

>Considering that literally anyone who roots any server at all - even servers that didn't use LetsEncrypt before - can generate new valid LetsEncrypt certificates

As opposed to any other CAs? There are plenty of other CAs that will happily grant a certificate if you prove control of a server that the domain resolves to.

>nothing generated has a password on it, I don't know if I would consider them really trustworthy.

If you have root on the server, can't you just dump the certificate out of memory, even if there's a password on it? short of using a HSM, you need the certificate decrypted so the server can use it.

Re: Chrome's Plan to Distrust Symantec Certificates

#32
post #28
post #3

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

Just so I'm understanding the implications of this correctly, my company uses certs issued by Thawte. Would these certs be affected by this move?

Seems so. The article says:

If you are a site operator with a certificate issued by a Symantec CA prior to June 1, 2016, then prior to the release of Chrome 66, you will need to replace the existing certificate with a new certificate from any Certificate Authority trusted by Chrome.

Re: Chrome's Plan to Distrust Symantec Certificates

#33

Earlier quoted context omitted.

Not only that, but they're doing things like Certificate Transparency - publishing every certificate they sign into public logs and they're funded and supported by some of the biggest names in online security and privacy. They're probably the most trustworthy CA on the planet.

Considering that literally anyone who gets even local access to any server at all, or can spoof one - even servers that have never used LetsEncrypt before - can generate new valid LetsEncrypt certificates, and nothing generated has a password on it, I don't know if I would consider them trustworthy. If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - an…

[deleted]

Re: Chrome's Plan to Distrust Symantec Certificates

#34

Earlier quoted context omitted.

Not only that, but they're doing things like Certificate Transparency - publishing every certificate they sign into public logs and they're funded and supported by some of the biggest names in online security and privacy. They're probably the most trustworthy CA on the planet.

Considering that literally anyone who gets even local access to any server at all, or can spoof one - even servers that have never used LetsEncrypt before - can generate new valid LetsEncrypt certificates, and nothing generated has a password on it, I don't know if I would consider them trustworthy. If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - an…

> Considering that literally anyone who roots any server at all, or can spoof one - even servers that have never used LetsEncrypt before - can generate new valid LetsEncrypt certificates, and nothing generated has a password on it, I don't know if I would consider them trustworthy.

This is true for the vast majority of all CAs.

> If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - and who is reading that to see if every server they have has been issued a cert unnecessarily, anyway?), LetsEncrypt is awesome.

Wouldn't you rather pick a CA that doesn't log all certificates publicly? (At least while that's still possible - i.e. till early next year.) If you're doing this on a massive scale with a CA that logs publicly, there is absolutely no way you're not getting caught.

Certificate Transparency Monitoring is fairly easy to set up, by the way. Even Facebook runs a public monitor you can use.

Re: Chrome's Plan to Distrust Symantec Certificates

#35

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.

If it makes the two of you feel any better, the US Supreme Court justices also don't agree on whether to use precise or approachable language. Different strokes.

http://legaltimes.typepad.com/files/garner-transcripts-1.pdf

Re: Chrome's Plan to Distrust Symantec Certificates

#36

Earlier quoted context omitted.

Not only that, but they're doing things like Certificate Transparency - publishing every certificate they sign into public logs and they're funded and supported by some of the biggest names in online security and privacy. They're probably the most trustworthy CA on the planet.

Considering that literally anyone who gets even local access to any server at all, or can spoof one - even servers that have never used LetsEncrypt before - can generate new valid LetsEncrypt certificates, and nothing generated has a password on it, I don't know if I would consider them trustworthy. If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - an…

A lot of non-EV certs are given out if you control one of about 6 pre-defined email addresses like webmaster@. The security is already lacking given SMTP's bad security architecture and I'd argue that LE's protocol is a lot better.

Re: Chrome's Plan to Distrust Symantec Certificates

#37
post #26

I want to thank the Chrome people that continued to investigate the initial issues with Symantec certificates rather than just take their word for it that it was a honest one-time mistake. I imagine there has been a lot of tension between Google and Symantec over the past year because of this, so it must not have been easy to keep poking at Symantec. After all, Symantec almost was one of the "too big too fail" CAs. A…

To add to this sentiment.

I think routine checks should done to all CAs, they are an important part of how "trust" works on the internet. and I see their importance only growing at this point.

Google should not be the only company trying to enact change in this area.

[edit: so many typos - oops]

Re: Chrome's Plan to Distrust Symantec Certificates

#38

Earlier quoted context omitted.

LE Wildcards should be around by then! Hopefully enough tooling will exist to make that migration seamless, or as seamless as cert migration can be.

LE wildcards are coming early 2018 I believe so you'll still have a month or two gap.

No action will be taken to impact users until March 15, 2018 at the earliest and only if you got your certificate before June 1, 2016. At least when it comes to any existing certificate (they are ambiguous about when they will cut off new certificates exactly).

Re: Chrome's Plan to Distrust Symantec Certificates

#39
post #31

Earlier quoted context omitted.

Considering that literally anyone who gets even local access to any server at all, or can spoof one - even servers that have never used LetsEncrypt before - can generate new valid LetsEncrypt certificates, and nothing generated has a password on it, I don't know if I would consider them trustworthy. If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - an…

>Considering that literally anyone who roots any server at all - even servers that didn't use LetsEncrypt before - can generate new valid LetsEncrypt certificates As opposed to any other CAs? There are plenty of other CAs that will happily grant a certificate if you prove control of a server that the domain resolves to. >nothing generated has a password on it, I don't know if I would consider them really trustworthy.…

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 manage the keys myself, and require only private key X could be used to sign Y, and manage it myself. They don't really let me set those requirements at the CA level - it's all on my own host + network security, which IMHO is unnecessarily risky.

Re: Chrome's Plan to Distrust Symantec Certificates

#40

Earlier quoted context omitted.

Not only that, but they're doing things like Certificate Transparency - publishing every certificate they sign into public logs and they're funded and supported by some of the biggest names in online security and privacy. They're probably the most trustworthy CA on the planet.

Considering that literally anyone who gets even local access to any server at all, or can spoof one - even servers that have never used LetsEncrypt before - can generate new valid LetsEncrypt certificates, and nothing generated has a password on it, I don't know if I would consider them trustworthy. If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - an…

Anyone who had the necessary access to a server could get a domain-validated certificate before LE existed, they didn't introduce that.

You can generate and handle the private key entirely yourself, without ever having LE code touch it if you want. You only need to generate CSRs from it.

And you now more than ever have tools to control this if you worry about it: CT logs (that you don't have to check yourself, thanks to free services that alert you about each new certificate for your domain) and CAA records

Post reply on HN