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

[Tor Bug Tracker & Wiki]

#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):

 I want to mention an alternative architecture, in case the native
 messaging aspect turns out to be too awkward to deal with.

 Fundamentally we need some kind of channel between meek-client and the
 browser, so that meek-client can send encoded HTTP requests to the
 browser, and the browser can send back encoded HTTP responses. With the
 old XPCOM extension, that channel was an `nsiServerSocket` that the
 extension opened itself. In the WebExtension Ihave been working on so far,
 with native messaging, the channel is a socket opened by the native shim,
 plus the stdio channel provided by the WebExtension API.

 An alternative is to have meek-client run a local web server, and the
 browser communicate with it by making local HTTP or WebSocket requests.
 Let's say WebSocket, that's a little easier to explain. meek-client starts
 a WebSocket server. The browser extension establishes a connection to the
 server. They then exchange serialized requests and responses.

 The thing that starts the local web server doesn't have to be meek-client
 itself; it could be a separate process. It could be part of meek-client-
 torbrowser. The important difference is that the separate process would
 not be a child of firefox. Compare with the diagram in comment:5:
 {{{
 tor
 └─meek-client-torbrowser
   ├─meek-client-webserver (opens a WebSocket socket on port YYYY, and a
 helper server on port XXXX)
   ├─firefox --headless (connects over WebSocket to 127.0.0.1:YYYY)
   └─meek-client --helper 127.0.0.1:XXXX
 }}}

 The communications channel would be (keeping in mind that there are other
 options, like combining meek-client and meek-client-webserver):
 {{{
 [meek-client] <-- helper protocol --> :XXXX [meek-client-webserver] :YYYY
 <-- WebSocket --> [firefox]
 }}}

 One difficulty is how to inform the browser extension of the local web
 server's port number. Before the whole communications channel is set up,
 there are limited ways to get information into the browser extension. I
 don't think you can even read environment variables from a browser
 extension. One option is of course to run the web server on a consistent
 port, but then you have to deal with the case that the port number is
 already in use.

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