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.
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.
ideally not requiring new complicated code in meek-server itself
If you're OK with some amount of new code, there are Go client libraries that might be sufficiently flexible:
- https://github.com/xenolf/lego - https://ericchiang.github.io/go/tls/lets/encrypt/letsencrypt/2015/11/13/a-le...
I'll give this a try soon if you haven't already.
On Fri, Mar 25, 2016 at 1:54 PM, David Fifield david@bamsoftware.com wrote:
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. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, Apr 08, 2016 at 05:28:45PM -0700, George Tankersley wrote:
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.
ideally not requiring new complicated code in meek-server itself
If you're OK with some amount of new code, there are Go client libraries that might be sufficiently flexible:
- https://github.com/xenolf/lego - https://ericchiang.github.io/go/tls/lets/encrypt/letsencrypt/2015/11/13/ a-letsencrypt-client-for-go.html
I'll give this a try soon if you haven't already.
Thanks. You are welcome to try. I haven't done anything yet.
My ideal situation would be that I can run an acme client *outside* of meek-server, the same way I can do for Apache. Something like this: letsencrypt-auto certonly [some other arguments, maybe --webroot] meek.bamsoftware.com
Adding acme code to meek-server seems less desirable to me. I am trying to keep the feature count low to keep the bug count low. meek-server is under 500 lines and I wouldn't want to add more than, say, 200 lines for acme support. It might have to write new certificate files to the filesystem, which means worrying about privileges. It's possible, though, that I don't properly understand how an acme library should work and these concerns aren't appropriate.
My current inclination is to add an --acme-webroot option to meek-server, and install a restricted http.Handler that allows serving files from that directory. It will only serve files whose names are in the specific format that acme requires. Maybe it can only serve files whose creation time is recent, as an additional safeguard against accidentally serving non-acme files.
-
David Fifield -
George Tankersley