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

 I added proxy support here:
  * [https://gitweb.torproject.org/pluggable-
 transports/meek.git/commit/?h=webextension&id=f9c9f5aed26d3e01f766668da40bbed97984f0f7
 Allow specifying a proxy.]
  * [https://gitweb.torproject.org/pluggable-
 transports/meek.git/commit/?h=webextension&id=e1ff5cdec9719853a6b0b8569b95196fe18e1bb5
 Detect errors of proxy.onRequest.]
 Now I can bootstrap with
 {{{
 SOCKS4Proxy 127.0.0.1:1080
 }}}
 {{{
 SOCKS5Proxy 127.0.0.1:1080
 }}}
 {{{
 HTTPSProxy 127.0.0.1:3128
 }}}
 To test SOCKS4a/5 I used `ssh -D 1080`. To test http I used `ncat -l
 --proxy-type http`.

 The strategy to support proxies is similar to the strategy to modify
 headers. We can only set the proxy in a [https://developer.mozilla.org/en-
 US/docs/Mozilla/Add-ons/WebExtensions/API/proxy/onRequest proxy.onRequest]
 event listener. We use a lock to ensure that only one request is affected
 at a time.

 An unexpected complication was the error behavior of `proxy.onRequest`. If
 an error occurs in the event listener--say, you give it an unsupported
 `type`, or omit the `host` field--Firefox will log the error to the
 console but then proceed as if no proxy were configured. I didn't find a
 specification of what ''should'' happen, but it seems like it may be a
 bug, so I reported it here:
   https://bugzilla.mozilla.org/show_bug.cgi?id=1528873
 It's not the kind of problem that can happen unpredictably at runtime:
 either your configuration is right or it's wrong. But silently ignoring an
 error when a user has tried to configure a proxy seems wrong, so I
 implemented a conservative safeguard: a [https://developer.mozilla.org/en-
 US/docs/Mozilla/Add-ons/WebExtensions/API/proxy/onError proxy.onError]
 listener checks for an error in `proxy.onRequest`, and a
 [https://developer.mozilla.org/en-US/docs/Mozilla/Add-
 ons/WebExtensions/API/webRequest/onErrorOccurred
 webRequest.onBeforeRequest] listener cancels all requests if a proxy error
 has ever occurred. Unlike the listeners that modify headers and set the
 proxy per request, these listeners are static for the lifetime of the
 extension and don't need locks or unregistration logic.

 Next, I'm planning to try integration with Tor Browser. As noted in
 comment:9, the likely difficulty here will be the static paths and
 registry entries used by the native messaging API.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29347#comment:11>
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