[tor-dev] RFC: Using `utls` in meek_lite.

[David Fifield]

On Mon, Jan 21, 2019 at 05:12:41AM +0000, Yawning Angel wrote:
> I just pushed a change to obfs4proxy master to use `utls` to mask the
> ClientHello signature (currently Chrome 70.x).
> 
> https://gitlab.com/yawning/obfs4/commit/4d453dab2120082b00bf6e63ab4aaeeda6b8d8a3
> 
> I understand that this is being worked on for the original meek (see:
> https://bugs.torproject.org/29077), but I felt inspired and it was
> relatively easy to get something working.

Thanks, you found a clever approach that I hadn't thought of. I tried
just setting DialTLS on the main http.Transport--that doesn't work
because net/http doesn't know that utls has negotiated HTTP/2, and
starts sending HTTP/1.1 on an HTTP/2 connection. Setting DialTLS on an
http2.Transport works, but only with HTTP/2 servers.

If I may interpret, your code builds an http.RoundTripper wrapper around
http.Transport and http2.Transport. When the caller makes its first
request, the wrapper initiates the utls connection, then inspects what
protocol was negotiated with ALPN, and creates its own internal
http.Transport or http2.Transport as appropriate. Then, it simply
forwards all requests to its internal transport--also setting DialTLS on
the internal transport so that future connections will also use utls,
but re-using the same transport instead of making a new one each time.

This looks better than what I was trying to do. I will probably start
working on doing the meek-client implementation in this style.

As for the TODO, my plan was was to expose a "utls" SOCKS arg to make it
configurable per bridge, and just reuse the utls Client Hello ID names:
	utls=HelloChrome_Auto