[tor-dev] Using Let's Encrypt for meek bridges
David Fifield
david at bamsoftware.com
Sat Apr 9 03:20:24 UTC 2016
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.
More information about the tor-dev
mailing list