[nmglug] lets encrypt

[Anthony J. Bentley]

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