Bye bye Verisign ...

dalecosp

http://www.commitstrip.com/en/2016/06/13/the-end-of-an-expensive-era/

sneakyimp

I dunno, man. Handing your site's security over to some black box written by some bloke out on the internet somewhere doesn't sound all that smart to me. I agree that paying $400/yr for a cert is ridiculous, and some downward price pressure is absolutely necessary (these should cost roughly the same as a domain registry or less IMHO) BUT I mean come on is it really safe to automate cert renewal, delegating root permissions to some script that does god-knows-what and then rely on some remote entity to sign the script? It is precisely this kind of reliance on other people's code that is likely to compromise security even further. I tried to start a thread about this here back in April but no one bit.

I had marginally better luck over at linuxquestions:
http://www.linuxquestions.org/questions/linux-security-4/free-certs-thoughts-on-letsencrypt-4175578129/

I'd be very curious to hear other people's thoughts on LetsEncrypt.

laserlight

sneakyimp wrote:
Handing your site's security over to some black box written by some bloke out on the internet somewhere doesn't sound all that smart to me.

It's the same problem as with Verisign, or any CA: you have to trust Trent. The difference is that if you're paying Trent, you probably can trust him more, but still. In the case of Let's Encrypt, you trust that although you're not paying Trent, Trent has the incentive to be trustworthy otherwise browsers and others will stop including their root certs, and they become no better than a self-signed solution.

sneakyimp wrote:
BUT I mean come on is it really safe to automate cert renewal, delegating root permissions to some script that does god-knows-what and then rely on some remote entity to sign the script? It is precisely this kind of reliance on other people's code that is likely to compromise security even further.

Maybe, maybe not. If you are in doubt, review the existing scripts, or if you find them to be black boxes, write your own scripts for automation (in which case you should get someone else to do a code review too), or keep renewing and installing the certs manually every few months. Note that this is true of everything: recall Ken Thompson's Reflections on Trusting Trust.

sneakyimp

laserlight;11059057 wrote:
It's the same problem as with Verisign, or any CA: you have to trust Trent.

If I'm not mistaken, your visitors have to trust Trent (he could lie to them and say why yes! That other IP (which actually belongs to Mallory) is coughing up a valid cert for sneakyimp-domain.com. This would of course be bad, but it would not expose your production system to a script, running as root, which would install some cert supplied by a potentially compromised system. Do I have that right? I suppose I will in fact need to look into the actions performed by this installation script.

laserlight;11059057 wrote:
The difference is that if you're paying Trent, you probably can trust him more, but still. In the case of Let's Encrypt, you trust that although you're not paying Trent, Trent has the incentive to be trustworthy otherwise browsers and others will stop including their root certs, and they become no better than a self-signed solution.

That you might pay Verisign is a material difference. I'm not sure what the terms are, but their certs come with substantial warranties. There is another difference: Lets Encrypt certs expire very quickly. This frequent renewal might provide some benefit in that a compromised certificate would not persist as long -- on the other hand, having to repeat the subscription renewal process opens more opportunities for exploitation by Mallory. They offer their reasons for the short lifetime, but I can't help wondering if their organization might be pressured by some facist state to somehow issue a compromised certificate or something. Offhand, I can't really think of what the State might force them to do. If I'm not mistaken, both private key and public key are generated on my system and my private key cannot be deduced from my public key. The certificate issued would only add a signature to my public key. I suppose it is necessary to review the process to determine what influence the certificate issuing system might exert on my site's key generation.

laserlight;11059057 wrote:
Maybe, maybe not. If you are in doubt, review the existing scripts, or if you find them to be black boxes, write your own scripts for automation (in which case you should get someone else to do a code review too), or keep renewing and installing the certs manually every few months.

Seems to me that the cost of this effort might quickly amount to the cost of a cert signed by Verisign (now Symantec). Geotrust certs are as little as $149 and come with a $500K warranty of some kind.

laserlight;11059057 wrote:
Note that this is true of everything: recall Ken Thompson's Reflections on Trusting Trust.

Thanks for this and your insights. Extremely helpful as usual.

dalecosp

The ISRG contains members from U Mich, Stanford, Mozilla, Akamai, Cisco, and several others. Their top level CA is signed by IdenTrust, who I could pay if we had to. That's really my biggest question on the whole thing ... how did they convince Identrust to add their authority to LetsEncrypt when it's really a competitor to their product?

But practically, when the management is talking fried chicken instead of steak for the Christmas party this year, it seems a good idea to cut costs. I'm covering six or seven subdomains with one cert, which is very pricey when you pay Comodo/Verisign/GoDaddy, etc.

As for being a "black box", the docs pretty much say what they do, and I have checked most of the files they create, and I've read some of their code.

Sure, they could install a backdoor if they wanted to. But for that matter, so could the Apache Foundation, the nginx people, MySQL (which is owned by Oracle now, so, big bad corporate types have software on my F/OSS servers --- hello to the NSA?), and so could Zend themselves, for that matter (hello also Mossad, which might be scarier than the US types).

Part of the F/OSS principle is that peer review, and being exposed for review, will keep vendors on the "up & up". And in the end, it's not even so much that I trust the cert authority; more importantly, are our users trusting us? That green lock on 7 sites for free? We decided we were able to take the risk.

sneakyimp

I apologize if my attitude is a bit of rain on what sounds like a really enjoyable money-saving parade. I'm sure LetsEncrypt is probably safe, but something like this really makes me want to pull out the old tin foil hat just so I understand what's really going on to, you know, burnish the ol' security credentials.

dalecosp;11059081 wrote:
The ISRG contains members from U Mich, Stanford, Mozilla, Akamai, Cisco, and several others. Their top level CA is signed by IdenTrust, who I could pay if we had to. That's really my biggest question on the whole thing ... how did they convince Identrust to add their authority to LetsEncrypt when it's really a competitor to their product?

Good question! It looks like Identrust has one of those typical, poorly-styled websites. It sort of screams 90s/2000s. Their primary line of work appears to be issuing certs and charging for it. Signing LetsEncrypt's CA seems like a very good example of shooting oneself in the foot. Are they obligated legally to sign it? Or maybe someone should inquire directly to them or to their parent company. One also wonders what interest the ISRG (distinct from the other ISRG which does essentially the same mission) may have in doing this. This mediocre article credits the EFF for LetsEncrypt and the EFF are in fact listed as a platinum sponsor. This tends to give me a lot more confidence in the project. I like the EFF -- at least the tenor of their communications. I also just noticed that IdenTrust is listed among the gold sponsors.

dalecosp;11059081 wrote:
But practically, when the management is talking fried chicken instead of steak for the Christmas party this year, it seems a good idea to cut costs. I'm covering six or seven subdomains with one cert, which is very pricey when you pay Comodo/Verisign/GoDaddy, etc.

In my understanding, wildcard certs can be quite affordable (but risky), but multi-subdomain certs are still expensive. But yes this seems like substantial savings.

dalecosp;11059081 wrote:
As for being a "black box", the docs pretty much say what they do, and I have checked most of the files they create, and I've read some of their code.

See anything noteworthy?

dalecosp;11059081 wrote:
Sure, they could install a backdoor if they wanted to. But for that matter, so could the Apache Foundation, the nginx people, MySQL (which is owned by Oracle now, so, big bad corporate types have software on my F/OSS servers --- hello to the NSA?), and so could Zend themselves, for that matter (hello also Mossad, which might be scarier than the US types).

I wouldn't say this keeps me awake at night, but I do wonder sometimes if there is any such thing as a "secure" system. I have frequently wondered why the U.S. doesn't pony up and pay for a huge audit of linux so they can have something safe for their sensitive operations.

dalecosp;11059081 wrote:
Part of the F/OSS principle is that peer review, and being exposed for review, will keep vendors on the "up & up". And in the end, it's not even so much that I trust the cert authority; more importantly, are our users trusting us? That green lock on 7 sites for free? We decided we were able to take the risk.

All true and your choice seems an entirely reasonable one. I wonder about the 'peer review' principle. Seeing how the Javascript world is going, there seems to be a headlong rush to stack up as many "tools" as possible and build one's slapdash website on top of the wobbling result. I suppose I will try and contribute a little to the peer review work that needs to be done. I also agree that user trust is what really matters.

dalecosp

sneakyimp;11059091 wrote:
I apologize if my attitude is a bit of rain on what sounds like a really enjoyable money-saving parade. I'm sure LetsEncrypt is probably safe, but something like this really makes me want to pull out the old tin foil hat just so I understand what's really going on to, you know, burnish the ol' security credentials.

I don't at all disapprove of your attitude or tinfoil hat. I actually wish that we had more security minded folks in our company. I think my stress level would be slightly lower if I knew that I wouldn't be called in to fix some incident, whether employee workstation or company server, in the next few months. I'd say I have averaged at least one/year so far ... probably 1.x/year.

In my understanding, wildcard certs can be quite affordable (but risky), but multi-subdomain certs are still expensive. But yes this seems like substantial savings.

Your understanding lines up pretty well with what I discovered in researching before I pulled this trigger.

See anything noteworthy?

Not yet. I have a basic understand of Python but not necessarily the entire packaging system, so I've not yet found the source of all the things that were "imported" in various places.

I wouldn't say this keeps me awake at night, but I do wonder sometimes if there is any such thing as a "secure" system. I have frequently wondered why the U.S. doesn't pony up and pay for a huge audit of linux so they can have something safe for their sensitive operations.

Well, for one thing they've done, see TrustedBSD (and note the list of sponsors).

All true and your choice seems an entirely reasonable one. I wonder about the 'peer review' principle. Seeing how the Javascript world is going, there seems to be a headlong rush to stack up as many "tools" as possible and build one's slapdash website on top of the wobbling result. I suppose I will try and contribute a little to the peer review work that needs to be done. I also agree that user trust is what really matters.

I do also wonder how many people among the millions that are now "coders" actually read other people's code. I don't read as much as I probably should.