Formerly, RoundTrip simply deferred to the global httpRoundTripper (the
one we would use if we were not using uTLS) for any http (as opposed to
https) requests. However, we allow setting a proxy on UTLSRoundTripper
that can be different from the proxy set on the global httpRoundTripper.

In practice, the global httpRoundTripper probably *would* have the same
proxy setting, just because of how the PT protocol only allows a single
proxy and how we initialize everything together. But there's nothing at
the UTLSRoundTripper layer that enforces that, so it's better if we
don't assume it. UTLSRoundTripper is already slightly weird because of
the rule about not mixing http/1.1 and h2; this change means that http
URLs don't add any additional weirdness.

panic means the channel won't close, which means the parent goroutine
will hang. Also take the opportunity to log an error message.

Was aiming for parity with net/http.

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 is needed for an HTTP proxy. A CONNECT request is host:port but the
port can only be numeric.

Plan to use this for testing.

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

This was a regression added in 3fe68658.

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

This is for compatibility with obfs4proxy meek_lite.

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.

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).

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.