On Mon, Feb 15, 2016 at 10:36:36AM -0700, Sam Noble wrote:

On Sat, Feb 13, 2016 at 12:02:11PM -0700, Jason Schaefer wrote: This is super-cool. I didn't think this would work on dreamhost shared-hosting anytime soon. and it totally does.

Thanks mozilla, eff, dreamhost etc!

Somebody do the pondering for me, I have questions about general use of lets' encrypt (or any automated TLS cert renewal setup.) regarding best practice for ensuring I'm getting as much out of the TLS encryption model as I can. And additional questions in the case of $WEBHOST (or any service provider) managing certs for their users. I love that I can have encrypted connections without paying or forcing visitors to be clicking on "Yeah I know that the cert is unsigned" in browsers (or worse not being able to use an https api with android programs.) But what's due diligence for my part of this transaction? I run a script on my webserver or click a button on dreamhost's page and suddenly I get free TLS? Great if that's all it takes but I'm skeptical. So for any LE user there are a few issues, the letsencrypt model has short duration certs, so they'll be changing often. How am I supposed to keep track of when they've changed? Do I need to? Should I keep track of some identifier of LE's Certificate Authority and verify that's the one being used to sign my LE certs? And then the much bigger leap comes with the setup I'm actually using. Obviously using a cheap shared web-hosting account like the one I have has plenty of risks with respect to how much I can trust the software I run there, I have to trust their admins in lots of cases, as one does on any machine where someone else has root. (And physical access, and legal ownership, etc.) Great, but I don't have access to the private TLS key, I don't know who else has access to the private key on my sites. I'm thinking this is still a huge improvement over plaintext HTTP right? Weren't there a bunch of nasty tricks that we learned about from that guy Edward, that are thwarted just by HTTPS regardless of the quality of the TLS used? Plus even in a hotel full of staff that all carry master keys, locking your door is often still a good idea right? But has anyone been trolling LE or Dreamhost forums and mailinglists and have quick answers to all my concerns? -- sam

Sam Noble writes:

I love that I can have encrypted connections without paying or forcing visitors to be clicking on "Yeah I know that the cert is unsigned" in browsers (or worse not being able to use an https api with android programs.)

But what's due diligence for my part of this transaction? I run a script on my webserver or click a button on dreamhost's page and suddenly I get free TLS? Great if that's all it takes but I'm skeptical.

Your skepticism is warranted. Security issues must always be considered carefully. What does Let's Encrypt give you? It gives you confidence that there is an unbroken, secure connection between your webserver (serving a LE-verified certificate) and a browser. What attacks does this defeat? - Passive sniffing of the connection between the browser and server; likely attackers include ISPs, governments, and some jerk using the coffee shop wifi. - Active man-in-the-middle that modifies page content; likely attackers include ISPs (such as those that insert ads in unencrypted webpages), governments, and some jerk using the coffee shop wifi. (C.f.: Upside-down-ternet, http://www.ex-parrot.com/~pete/upside-down-ternet.html) What kinds of attacks does this *not* defeat? - Virus-infected/adwared/trojaned browsers/machines - Compromised webservers (e.g., attackers using Wordpress exploits) - Evil webservers - Weaknesses in Let's Encrypt's signing infrastructure There are ways to prevent some of these, but HTTPS is not one of those ways. That doesn't mean HTTPS is bad or ineffective--it's just that these weaknesses should be kept in mind.

So for any LE user there are a few issues, the letsencrypt model has short duration certs, so they'll be changing often. How am I supposed to keep track of when they've changed? Do I need to? Should I keep track of some identifier of LE's Certificate Authority and verify that's the one being used to sign my LE certs?

Certificate signing requests via Let's Encrypt are done via encrypted, authenticated HTTPS connections to Let's Encrypt infrastructure. So as long as your Let's Encrypt client is properly checking HTTPS validity, you should be fine. It's worth mentioning that your private key is never sent to Let's Encrypt, only signed responses. So LE can't duplicate your cert, only sign it. For technical details, check out the ACME spec draft: https://tools.ietf.org/html/draft-barnes-acme-01

And then the much bigger leap comes with the setup I'm actually using. Obviously using a cheap shared web-hosting account like the one I have has plenty of risks with respect to how much I can trust the software I run there, I have to trust their admins in lots of cases, as one does on any machine where someone else has root. (And physical access, and legal ownership, etc.) Great, but I don't have access to the private TLS key, I don't know who else has access to the private key on my sites.

Yes, this is a real concern. Presumably your hosting agreement has some sort of policy that prevents them from misusing your data, and you would be able to take legal action if they violate it (but I'm not a lawyer and you shouldn't trust my commentary on law).

I'm thinking this is still a huge improvement over plaintext HTTP right?

Yes. One thing I really think people should be aware of is that the client you use to get certs signed by LE *does* have access to the certs. You should be very careful: don't use random Github "helper scripts" to do Let's Encrypt. I wouldn't even use the official client--while EFF does a lot of good policy-wise, I'm not inclined to trust their technical skills at writing simple, bug-free code. The client I recommend is letskencrypt, which uses a privilege-separated design to reduce risk of bugs compromising your keys. https://kristaps.bsd.lv/letskencrypt/ But you shouldn't just trust me; I'm a random guy from the internet. Research things yourself, and audit whatever codebase you use. This is a more general principle, too. Have a bias toward small, simple code that's easy to audit. And do audit it, or hire a programmer you trust to do so. Use filesystem permissions properly to reduce the damage an evil or compromised application can do. Run software as unprivileged users. There's not enough of this culture in the free software world (and said culture is almost nonexistent in the proprietary software world). -- Anthony J. Bentley