Since we cannot use any handshake that has a "h2" ALPN (like
HelloFirefox_63 or HelloChrome_70), let's use a randomized handshake.
HelloRandomizedNoALPN differs from HelloRandomized and
HelloRandomizedALPN in that it always omits ALPN.

The http.Transport still appears to make 10 independent connections,
each with its own randomized fingerprint...

Disables proxy support: I'm using http.Transport.DialTLS to hook into
utls, and http.Transport.Proxy is ignored when DialTLS is set. We'll
have to manually make our own proxy connections within DialTLS.

It doesn't work properly yet because the HelloChrome_Auto fingerprint
we're using includes "h2" in the ALPN extension, which causes the server
to think it should use HTTP/2. The client side, however, uses HTTP/1.1
because it disable automatic HTTP/2 configuration when DialTLS is set.
So you have an HTTP/1.1 client talking to an HTTP/2 server, and an error
message like this:
	error in handling request: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x00\x00\x12\x04\x00\x00\x00\x00\x00\x00\x05\x00\x10\x00\x00\x00\x03\x00\x00\x00\xfa\x00\x06\x00\x10\x01@"

As a workaround, I'm not calling UConn.Handshake() before returning the
UConn from DialTLS. This seems to cause the caller to remove the ALPN
extension, thereby negotiating HTTP/1.1 on both sides. The downside are
the loss of HTTP/2, and the fact that a missing ALPN extension means our
fingerprint doesn't match what it's supposed to.

The previous path had an additional "devtools/":
resource://gre/modules/devtools/Console.jsm

The current documentation gives the path without "devtools/":
https://developer.mozilla.org/en-US/docs/Tools/Browser_Console#Console.jsm

The path seems to have changed in ESR58, thereby breaking the extension:
https://bugs.torproject.org/26118
https://bugs.torproject.org/26477#comment:2

Add support for a TOR_BROWSER_MEEK_PROFILE environment variable which,
if present, contains the path to the HTTP helper browser profile.

Ignore SIGINT, honor TOR_PT_EXIT_ON_STDIN_CLOSE.

The logic erroneously assumed that there was at least one handler
running at the time a signal was received. If there was not, it would
wait forever for something handler-related to happen.

https://bugs.torproject.org/24875

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