Re: [tor-bugs] #11183 [Pluggable transport]: Make an HTTP requestor Firefox extension for meek-client

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

#11183: Make an HTTP requestor Firefox extension for meek-client
-------------------------------------+----------------------
     Reporter:  dcf                  |      Owner:  dcf
         Type:  project              |     Status:  assigned
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:  meek
Actual Points:                       |  Parent ID:  #10935
       Points:                       |
-------------------------------------+----------------------

Comment (by dcf):

 My current rough design for the extension is this. Open an
 [https://developer.mozilla.org/en-
 US/docs/XPCOM_Interface_Reference/nsIServerSocket nsIServerSocket] on a
 well-known port. Connections to the port will send a JSON blob describing
 an HTTP request to make, looking like
 {{{
 {
   "method": "POST",
   "url": "https://www.google.com/";,
   "header": {
     "Host": "meek-reflect.appspot.com",
     "X-Session-ID": "12345",
   },
   "body": "base64data",
 }
 }}}
 The extension parses the JSON and makes the request using
 [https://developer.mozilla.org/en-
 US/docs/XPCOM_Interface_Reference/nsIHttpChannel nsIHttpChannel]. The
 extension reads the response and sends it out as JSON on the original
 connection it received on the well-known port, like
 {{{
 {
   "status": 200,
   "header": { ... },
   "body": "base64data",
 }
 }}}

 Rationale for design decisions:
  * Why a listening socket for communication between meek-client and the
 extension, rather than some other IPC? I don't know enough IPC to know of
 another way that will work.
  * Why a well-known port instead of an ephemeral port? I don't know how
 the extension can listen on an ephemeral port and then tell meek-client
 what port to connect to. Maybe it would be easier to do if we ran a second
 browser and the second browser was a child process of the meek-client
 process.
  * Why JSON instead of an HTTP proxy (meek-client is already able to talk
 to an HTTP proxy)? The little reason is that being an HTTP proxy would
 require us to parse HTTP in the extension. I don't know if there's a
 standard library for that and I don't want another implementation of HTTP.
 [https://developer.mozilla.org/en-
 US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse JSON.parse] and
 [https://developer.mozilla.org/en-
 US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
 JSON.stringify] work fine for data serialization
 ([http://golang.org/pkg/encoding/json/#Marshal json.Marshal] and
 [http://golang.org/pkg/encoding/json/#Unmarshal json.Unmarshal] in
 golang). The big reason is that HTTPS through an HTTP proxy uses the
 [https://tools.ietf.org/html/rfc2616#section-9.9 CONNECT] method which
 merely tunnels the client's own TLS handshake.
  * Why [https://developer.mozilla.org/en-
 US/docs/XPCOM_Interface_Reference/nsIHttpChannel nsIHttpChannel] and not
 [https://developer.mozilla.org/en-
 US/docs/XPCOM_Interface_Reference/nsISocketTransportService#createTransport%28%29
 nsISocketTransportService.createTransport]? I tested
 nsISocketTransportService, and its TLS handshake doesn't have the
 next_protocol_negotation=http/1.1 extension that nsIHttpChannel and normal
 browser requests have.
  * Why use a separate meek-client program to talk to the extension, rather
 than tor talking to the extension directly (with the extension
 implementing the PT protocol)? meek-client already exists and works fine
 apart from its TLS signature. I don't know extension programming so well,
 and would prefer to have less code in the extension than more. It seems
 more difficult to run a browser as a managed transport. I would like to
 treat the browser-like HTTP service as a mostly independent layer. For
 example we may want to try plugging in a different browser than Firefox.
 (Firefox is the most compelling option only because it's already included
 in the browser bundle.)

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