https://bugs.torproject.org/29077#comment:22

Tor doesn't support this kind of proxy (https://bugs.torproject.org/26306),
but I want to support the same kinds of proxies with uTLS as are
supported using the native Go net/http, for ease of explaining the proxy
restrictions in the man page.

We use the same uTLS ClientHelloID for the TLS connection to the HTTPS
proxy, as we use for the TLS connection through the tunnel.

This adapts a technique that Yawning used in obfs4proxy for meek_lite:
https://gitlab.com/yawning/obfs4/commit/4d453dab2120082b00bf6e63ab4aaeeda6b8d8a3
https://lists.torproject.org/pipermail/tor-dev/2019-January/013633.html

It's activated by the new utls= SOCKS arg or --utls command line option.
The argument is the name of a uTLS ClientHelloID; e.g.,
HelloChrome_Auto. We omit HelloCustom (not useful externally),
HelloGolang (just don't use utls), and HelloRandomized (may negotiate
HTTP/1.1 or HTTP/2 at different times, which is incompatible with the
way the integration works).

When using HTTP/1, we copy default timeouts etc. from the Go
net/http.DefaultTransport. Unfortunately I don't know a way to do the
same for HTTP/2. Configuring an http.Transport and then calling
http2.ConfigureTransport on it doesn't work; it leads to the same
problem of an HTTP/1 client speaking to an HTTP/2 server.

We recognize utls=none and utls=HelloGolang as an alias for omitting
utls=. This is for compatibility with obfs4proxy meek_lite.
https://bugs.torproject.org/29077#comment:13

It causes an error when it uses something unsupported, like
username:password.

This was a regression added in 3fe68658.

socks5 since go1.9:
https://golang.org/doc/go1.9#net/http
https://github.com/golang/go/issues/18508
https://github.com/golang/go/commit/36f55a8b6125c9ae951487a0ad074b5c991f7b92

https since go1.10:
https://golang.org/doc/go1.10#net/http
https://github.com/golang/go/issues/11332
https://github.com/golang/go/commit/f5cd3868d52babd106e0509a67295690246a5252

As opposed to url= and front= SOCKS args.

The requirement to wait until handlers are finished, as well as the
complicated signal counting logic, was removed from pt-spec.txt in 2014.

https://bugs.torproject.org/26389

Compare
https://gitweb.torproject.org/pluggable-transports/goptlib.git/commit/?id=15f83653abbcced9003c96cc14edc5b2f82e0e0e

Copy them into an instance from the global settings, don't read the
global settings directly.

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.