[tor-bugs] #18655 [meek]: Make meek-server easy to use with Let's Encrypt

[Tor Bug Tracker & Wiki]

#18655: Make meek-server easy to use with Let's Encrypt
-------------------------+---------------------
 Reporter:  dcf          |          Owner:  dcf
     Type:  enhancement  |         Status:  new
 Priority:  Medium       |      Milestone:
Component:  meek         |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
 Reviewer:               |        Sponsor:
-------------------------+---------------------

Comment (by dcf):

 Replying to [comment:6 yawning]:
 >
 https://git.schwanenlied.me/yawning/meek/commit/b749b5846115d10ba5cc409f5f150362bb4dae57
 >
 > Untested, should work, if there's something wrong it should be trivial.
 Behavior is:
 >
 >  * If the cert/key fail to `stat()` or load when creating the listener,
 fail hard.
 >  * On each incoming connection, if the mtime of '''either''' the cert or
 key has changed, reload the certificate, otherwise use the cached cert.
 >  * Once the listener is created, failures to `stat()` or reload the
 certificate result in an error message logged at most once every 60s, and
 the existing cached certificate to be used.
 >
 > Note that `stat()`-ing 2 files every incoming connection may be a tad
 expensive (though that's outside the mutex).  Performance can be improved
 by only reloading once in a while (`gettimeofday()` is vDSO-ed on sensible
 systems), and by using a `RWLock` instead of a `Mutex`.  Both to me are
 pre-mature optimizations since TLS handshake crypto blows both 2 syscalls
 and slight lock contention out of the water overhead wise.
 >
 > I think the other half of this is easiest to implement via an `--acme-
 webroot` that lets meek-server serve files over port 80 like you mentioned
 in your tor-dev@ e-mail.

 Thanks. That's beautiful. I'll write tests for `certContext`.

 It occurs to me that an `--acme-webroot` option will only work if meek-
 server is listening with TLS on port 443 or with non-TLS on port 80. So I
 think I'll check that one of those is true, and if not, throw an error at
 startup if the user tried to use `--acme-webroot`. If they have something
 else running on 80 or 443, then they'll have to work out their own thing,
 for example running letsencrypt in standalone mode.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18655#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online