The former TLS-SNI challenge type is gone.
https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5a55777ed9a9c1024c00b241

The new HTTP-01 challenge type requires a listener on port 80. The
former TLS-SNI challenge just piggybacked on an additional HTTPS
listener on port 443, if necessary. The new listener on port 80 just
handles ACME business and nothing else.

https://bugs.torproject.org/24928

https://bugs.torproject.org/24642

Running meek-client-torbrowser with the environment variable
TOR_PT_EXIT_ON_STDIN_CLOSE=1 would cause meek-client to exit
immediately, as it sensed that its stdin was closed.
meek-client-torbrowser was running the meek-client subprocess with a nil
Stdin, which causes its stdin to be /dev/null (or NUL on Windows), which
returns an immediate EOF. So instead, give meek-client an StdinPipe and
just keep it open. (We could alternatively keep track of it and close it
when necessary, but that would take further refactoring.)

The commit where things would have first broken was
0ec986eb (part of tag 0.28), which
added TOR_PT_EXIT_ON_STDIN_CLOSE awareness to meek-client. But it was
not meek-client's fault.

This bug did not affect any releases of Tor Browser, despite that on
Windows we unconditionally set TOR_PT_EXIT_ON_STDIN_CLOSE=1 via
terminateprocess-buffer, because Tor Browser is still using tag 0.25,
which doesn't have the TOR_PT_EXIT_ON_STDIN_CLOSE change in meek-client.

Running meek-client-torbrowser without arguments would panic as it tried
to index the nonexistent arguments.

2018/01/11 21:02:07 running firefox command ["firefox" "--invisible" "-no-remote" "-profile" "TorBrowser/Data/Browser/profile.meek-http-helper"]
2018/01/11 21:02:07 firefox started with pid 23721
2018/01/11 21:02:08 killing PID 23721
panic: runtime error: index out of range

goroutine 1 [running]:
panic(0x4e95a0, 0xc42000a110)
        /usr/lib/go-1.7/src/runtime/panic.go:500 +0x1a1
main.runMeekClient(0xc420010589, 0xf, 0xc42000a2c0, 0x0, 0x0, 0x0, 0x10, 0xc42000e440)
        meek-client-torbrowser.go:267 +0x416
main.main()
        meek-client-torbrowser.go:354 +0x3d2

The user might have set up their own forwarding or reverse proxy that
doesn't require meek-server itself to listen on 443.

--port is meant to override TOR_PT_SERVER_BINDADDR, but it was not
overriding in the check for the presence of a bindaddr on port 443.

SMETHOD-ERROR meek The --acme-hostnames option requires one of the bindaddrs to be on port 443.

Remove instructions for configuring without HTTPS.

Since Go 1.8 http.Transport does not set Content-Length header
if body contains no bytes.
https://golang.org/doc/go1.8#net_http
https://go-review.googlesource.com/c/31445/

However some of domain fronts do inspect Content-Length header
and return 411 error when it is not set. This breaks connection
entierly since these packets do not travel beyond a frontend
to a meek server.

Closes #22865.

Just in case. Previously we only copied the first instance (as provided
by Header.Get).

Ignore SIGINT, handle TOR_PT_EXIT_ON_STDIN_CLOSE.

An unfortunate effect of using net/http ListenAndServe and
ListenAndServeTLS is that you don't get early errors like "permission
denied" and "address already in use"--they happen later which means they
appear only in the meek-server log, not in the tor log. Here we apply a
hack to hold on for a fraction of a second to see if the call errors,
hopefully long enough to catch most of such errors.

The net/http package provides ListenAndServe and ListenAndServeTLS
functions, but it doesn't provide a way to set up a listener without
also entering an infinite serve loop. This matters for
ListenAndServeTLS, which sets up a lot of magic behind the scenes for
TLS and HTTP/2 support. Formerly, we had copy-pasted code from
ListenAndServeTLS, but that code has only gotten more complicated in
upstream net/http.

The price we pay for this is that it's no longer possible for a server
bindaddr to ask to listen on port 0 (i.e., a random ephemeral port).
That's because we never get a change to find out what the listening
address is, before entering the serve loop.

What we gain is HTTP/2 support; formerly our copy-pasted code had the
side effect of disabling HTTP/2, because it was copied from an older
version and did things like
	config.NextProtos = []string{"http/1.1"}

The new code calls http2.ConfigureServer first, but that's not what's
providing HTTP/2 support. HTTP/2 support happens by default. The reason
we call http2.ConfigureServer is because we need to set
TLSConfig.GetCertificate, and http2.ConfigureServer is a convenient way
to initialize TLSConfig in a way that is guaranteed to work with HTTP/2.

I don't see a reason to make a copy when this is all we use; also
"go vet" complained:

meek-client.go:403: assignment copies lock value to httpTransport: net/http.Transport contains sync.Mutex

This causes a message to appear in tor's log. Otherwise, with no log
file to write to, there's no indication of what the error was that
caused the transport plugin to fail.

https://bugs.torproject.org/20451

Sets the notification email for Let's Encrypt.

The inspiration for this code came from George Tankersley's patch:
	https://bugs.torproject.org/18655#comment:8
	https://github.com/gtank/meek/tree/letsencrypt

The meek-server code is partially cribbed from the Snowflake server
code:
	https://trac.torproject.org/projects/tor/ticket/18654#comment:7
	https://gitweb.torproject.org/user/dcf/snowflake.git/diff/?h=letsencrypt&id=1f8be86a01&id2=af70d49e96

Entirely untested, probably correct.  The callback used to feed the TLS
Listener the certificate was introduced in Go 1.6, so that version or
newer is now required.

Some others are used in examples and will need to be reworked.

See https://bugs.torproject.org/21342.

On OSX, use the TOR_BROWSER_TOR_DATA_DIR environment variable value
(if available) to determine the location of the meek browser profile.
This fixes a problem where meek-client-torbrowser attempted to use a
path under /Applications/TorBrowser-Data, to which regular users may
not have write access.