[tor-dev] Using Let's Encrypt for meek bridges

[David Fifield]

I'm looking for ideas of good ways to handle TLS certificates and their
renewal for meek bridges. I want to use Let's Encrypt for this process,
and I hope that someone who knows Let's Encrypt well can contribute some
ideas.

All three of the meek bridges use HTTPS to receive connections from the
CDN, so they need TLS certificates. For example, when you use
meek-azure, your traffic is forwarded to the bridge at
https://meek.bamsoftware.com/. How it works now is I do the usual domain
validation procedure with a CA, receive an email to show that I control
the domain, install the cert and key, and then run the server like this:
	meek-server --cert /etc/meek/cert.pem --key /etc/meek/key.pem

When I used Let's Encrypt in the past, using the --webroot option, it
wanted to write a file to the URL path "/.well-known/acme-challenge/{token}".
That won't work for meek-server as it exists today, because meek-server
never serves files from the filesystem. But it could. Perhaps we could
add an option like --acme-webroot that would allow serving files from a
single whitelisted directory.

I notice that there are other ways of proving domain ownership (HTTP,
TLS SNI, DNS). Maybe we could use one of those?
https://ietf-wg-acme.github.io/acme/#identifier-validation-challenges

I also note that there are third-party plugins:
https://github.com/letsencrypt/letsencrypt/wiki/Plugins
Maybe there could be a plugin for meek-server (ideally not requiring new
complicated code in meek-server itself).

Currently you have to restart meek-server in order to make it notice a
changed certificate and key file. It would be better if that were not
necessary--maybe we could periodically stat the files, and re-load them
if they have changed?

This is going to be an issue for Snowflake as well, because we will want
to use WebSocket over TLS for the server component.