Re: [tor-bugs] #29347 [Obfuscation/meek]: Rewrite meek-http-helper as a WebExtension

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#29347: Rewrite meek-http-helper as a WebExtension
------------------------------+--------------------------
 Reporter:  dcf               |          Owner:  dcf
     Type:  enhancement       |         Status:  assigned
 Priority:  Medium            |      Milestone:
Component:  Obfuscation/meek  |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:  webextension      |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:
------------------------------+--------------------------

Comment (by dcf):

 Replying to [comment:4 mcs]:
 > I might be pleasantly surprised, but I suspect it will be challenging to
 reimplement it as a Webextension while remaining compatible with the
 existing external interface. For example, I don't think there is an easy
 way to write to stdout.

 I haven't tried it all yet, but I've sketched it out mentally and I
 haven't found any showstoppers yet. (I found and appreciated you catalog
 of API differences at #17248.) [https://developer.mozilla.org/en-
 US/docs/Web/API/Window/dump window.dump] still works for writing to
 stdout, as long as the pref browser.dom.window.dump.enabled is set. I'm
 not hung up on 100% compatibility, but fundamentally we need some way for
 meek-client to send specifications of HTTP requests into the browser and
 receive responses (currently we have the browser open a local TCP socket),
 so I think you're right, we will need the native messaging API. Instead of
 having the browser open its own socket, it will spawn a subprocess to open
 the socket and then pass information to/from the subprocess. This is the
 process tree I envision:
 {{{
 tor
 └─meek-client-torbrowser
   ├─firefox --headless
   │ └─socket_shim (opens a socket on 127.0.0.1:XXXX)
   └─meek-client --helper 127.0.0.1:XXXX
 }}}

 meek-client and what I've here called socket_shim communicate over a local
 TCP socket. The socket_shim can communicate its unpredictable port number
 XXXX upward through the same native messaging API connection that it uses
 to exchange HTTP requests/responses.

 > I was hoping the new direction for the Tor Browser meek client would be
 to stop using a real browser (but that assumes the TLS fingerprint
 spoofing works well enough).

 That is the plan—there's a near-merge-ready branch at
 comment:15:ticket:29077 that, if you have time, I'd appreciate you having
 a look at. Using obfs4proxy meek_lite is also an option, since obfs4proxy
 also integrated uTLS.

 The headless Firefox WebExtension still has value for ESNI. Firefox has an
 ESNI implementation and Go doesn't. That's what led me to make this
 ticket—I wanted to try meek-client with ESNI in place of domain fronting,
 and found that a Firefox that is new enough to support ESNI is also too
 new to support the current browser extension 😅

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs