Amusing that security.googleblog.com itself is using a TLS certificate ultimately signed by GeoTrust Inc, which is owned by Symantec.
Chrome's Plan to Distrust Symantec Certificates
41–50 of 207 posts
Re: Chrome's Plan to Distrust Symantec Certificates
#42One of the happiest days of my life was when a Symantec support person, very courteously, helped me remove every Symantec product from my computer.
i remember needing a util for this: https://support.norton.com/sp/en/us/home/current/solutions/v... was a key component of my debloating efforts back in the XP days.
Norton protect quietly reinstalled itself after I ran that tool.
Oracle snuck it onto my system in a java update and I ended up having to dig through the registry and disk to weed it out. It is malware, plain and simple.
Re: Chrome's Plan to Distrust Symantec Certificates
#43Earlier 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…
I think it's a valid criticism, not LE but industry as a whole. Intel should add usable HSM in every cheap laptop, not even talking about servers instead of their ME backdoors. Technology is there, it's cheap and it's needed.
Re: Chrome's Plan to Distrust Symantec Certificates
#44"including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL" RIP RapidSSL wildcard
Also note that GeoTrust is Google's root CA.
Re: Chrome's Plan to Distrust Symantec Certificates
#45Earlier quoted context omitted.
>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 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?
CAA records. If you want full control over when issuance happens, you can even set the list of allowed CAs to empty and only change it when you actually want a certificate.
> And finally, say I wanted to use LetsEncrypt, but I wanted to manage the keys myself
If someone can submit a CSR and complete the challenges they get a signed cert, yes, just like with other DV-CAs. LE code (certbot or other clients) doesn't have to touch your private keys, as long as you give them CSRs, as with other CAs.
Re: Chrome's Plan to Distrust Symantec Certificates
#46Earlier quoted context omitted.
>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 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 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.
I'm not quite sure what you're saying here. Do you want the ability to issue certificates under your own (constrained) intermediate certificate? That's unfortunately not possible under the current Baseline Requirements unless you get audited as a CA.
If you just want to use your own private key, that's of course possible (in fact, there's no way for Let's Encrypt to generate a key for you). Or is it that you want to limit limit issuance for domain X to key Y? What other CA allows you to do that? And how would you prevent some other CA from issuing a certificate for a different key, even if Let's Encrypt would support such a feature? With that in mind, it becomes clear that in the end it's up to your host and network security again, even with such an agreement in place.
Re: Chrome's Plan to Distrust Symantec Certificates
#47Surely the distrust doesn't apply to websites with the Norton Secured Seal, the most trusted mark on the internet: https://www.symantec.com/page.jsp?id=seal-transition
Re: Chrome's Plan to Distrust Symantec Certificates
#48Earlier 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…
That... is the point of the DV cert?
Re: Chrome's Plan to Distrust Symantec Certificates
#49Earlier quoted context omitted.
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.
Why create a new word when we can just add a new adjacent meaning to an existing nearby word...
Language is mutable for this reason. If we didn't add any words but just kept using "nearby words" then we would be DANGER NO GO.
Re: Chrome's Plan to Distrust Symantec Certificates
#50Earlier quoted context omitted.
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).
> they are ambiguous about when they will cut off new certificates exactly
They are? It seems pretty clear to me. Symantec's old infrastructure will be distrusted in Chrome beta in September 2018. At that point, no certificates issued by Symantec's old root certs (including those issued after June 1, 2016) will be trusted.