[tor-bugs] #29077 [Obfuscation/meek]: uTLS for meek-client camouflage

[Tor Bug Tracker & Wiki]

#29077: uTLS for meek-client camouflage
------------------------------+------------------------------
 Reporter:  dcf               |          Owner:  dcf
     Type:  enhancement       |         Status:  needs_review
 Priority:  Medium            |      Milestone:
Component:  Obfuscation/meek  |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:  moat utls         |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:
------------------------------+------------------------------
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Here is a new candidate: meek branch [https://gitweb.torproject.org
 /pluggable-
 transports/meek.git/log/?h=utls_2&id=6c2cad6ce0e1d0d23ec88edb7942362de2552b0e
 utls_2]

 This is a rewrite using the obfs4proxy-inspired technique (comment:4),
 with a few implementation differences. Instead of `dialTLS` being attached
 to the `RoundTripper` wrapper with a distinguised error code, use a
 standalone `dialUTLS` function. Store the state for the dynamically
 created `Transport` in a closure rather than in the parent struct. Raise
 an error if the ALPN changes.

 You control which fingerprint to use with a SOCKS arg, like
 `utls=HelloChrome_Auto`. With the SOCKS arg, it uses the stdlib net/http
 as before. Using `utls=` with `--helper` is an error.

 Currently this breaks proxy support, because previously we were using the
 built-in proxy support of net/http, and we can't do that anymore with
 uTLS; we'll have to make our own proxy connections. I'll restore proxy
 support separately.

 I've removed HelloRandomized and HelloGolang from the table of allowed TLS
 fingerprints. HelloRandomized because
 [https://lists.torproject.org/pipermail/tor-dev/2019-January/013639.html
 it can negotiate different ALPN], and HelloGolang because that's ideally
 equivalent to omitting the `utls=` arg. I'm open to having it recognize
 `utls=HelloGolang` as an alias for omitting the `utls=` arg, because
 compatibility with meek_lite is the most important thing here.

 When creating the internal `http.Transport`, I think I'd like to make it
 have the same default settings as `http.DefaultTransport` with respect to
 timeouts, idle connections, etc. So I'm thinking of cloning the public
 fields of `http.DefaultTransport` using the reflection trick from
 comment:11:ticket:12208. Unfortunately `http2.Transport`
 [https://github.com/golang/go/issues/16581 doesn't expose configuration
 options] in the same way. Maybe it doesn't matter much? My main concern
 here is not having infinite timeouts.

 I tested the TLS fingerprint with a few different configurations.
 ||=configuration =||=fingerprint =||=  seen (all time)=||
 ||no camouflage ||[https://tlsfingerprint.io/id/c4b0fe116abff001
 c4b0fe116abff001]
 [https://web.archive.org/web/20190125221734/https://tlsfingerprint.io/id/c4b0fe116abff001
 archive] ||  0.01%||
 ||`--helper` (Tor Browser 8.0.4 / Firefox 60.4.0esr)
 ||[https://tlsfingerprint.io/id/bb94e801f7aee52b bb94e801f7aee52b]
 [https://web.archive.org/web/20190125221851/https://tlsfingerprint.io/id/bb94e801f7aee52b
 archive] ||  0.58%||
 ||`utls=HelloChrome_70` ||[https://tlsfingerprint.io/id/bc4c7e42f4961cd7
 bc4c7e42f4961cd7]
 [https://web.archive.org/web/20190125222100/https://tlsfingerprint.io/id/bc4c7e42f4961cd7
 archive] ||  3.54%||
 ||`utls=HelloFirefox_63` ||[https://tlsfingerprint.io/id/6bfedc5d5c740d58
 6bfedc5d5c740d58]
 [https://web.archive.org/web/20190125222153/https://tlsfingerprint.io/id/6bfedc5d5c740d58
 archive] ||  1.66%||

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29077#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online