GitLab

Now that meek and meek_lite have or will soon have support for TLS camouflage using uTLS (#29077 (moved)), we have the option of using that instead of the meek-http-helper headless Firefox extension.

The torrc line:

ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- ./TorBrowser/Tor/PluggableTransports/meek-client

will lose the meek-client-torbrowser to become just

ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-client

In bridge_prefs.js, the bridge line will get an additional utls parameter:

meek 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com utls=HelloIOS_Auto

There's the option of continuing to use the same meek repo as we do now; or of removing that code and using obfs4proxy instead, since they both have uTLS support. Using obfs4proxy will have the advantage of smaller packaging, because there will be one binary instead of two.

There's one more complication, which is tor-launcher and Moat. tor-launcher has its own meek configuration separate from Tor Browser's. It gets the path to the meek-client executable from the control port (ultimately from torrc-defaults), but it has its own version of the url= and front= parameters, and it passes those to the executable to the executable as -url and -front command line arguments, not as SOCKS args. meek-client with uTLS has a -utls command line arg, so that's easy to adapt; but since obfs4proxy doesn't understand those command line args, either obfs4proxy would have to add them, or tor-launcher would have to start passing them as SOCKS args.