[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #9349 [Flashproxy]: flashproxy facilitator: Allow clients to specify transports

#9349: flashproxy facilitator: Allow clients to specify transports
------------------------+---------------------------------------------------
 Reporter:  asn         |          Owner:  dcf  
     Type:  task        |         Status:  new  
 Priority:  normal      |      Milestone:       
Component:  Flashproxy  |        Version:       
 Keywords:              |         Parent:  #7167
   Points:              |   Actualpoints:       
------------------------+---------------------------------------------------

Comment(by dcf):

 Replying to [comment:2 asn]:
 > I atttach a patch for `doc/design.txt` of flashproxy to document the new
 advanced client registrations.

 Thank you, my man. `design.txt` is a good place to document it. Beware
 that `design.txt` is somewhat out of date. Here are my thoughts.

 There are three things to consider: the set of transport chains the client
 supports, the set of transport chains the proxy supports, and the set of
 transport chains the relay supports.

 By "transport chain" I mean something like obfs3|websocket. What is nice
 about this is that the proxy only needs to support the outermost layer. A
 proxy that supports websocket can connect a client and server that speak
 obfs3|websocket (or rot13|obfs3|websocket etc.), without needing to know
 that there is obfs3 underneath. Everything up to the last component in the
 chain must be identical between client and relay; e.g., an obfs3|websocket
 client would not be able to talk to a rot13|websocket relay, even if there
 is a websocket proxy between them.

 To give three examples of realistic outermost layers, we have websocket,
 webrtc, and plain tcp. We can imagine, for instance, a JavaScript proxy
 capable of speaking both websocket and webrtc. Such a proxy could connect
 an obfs3|webrtc client with an obfs3|websocket relay. A standalone proxy
 might be capable of making plain tcp connections; it could connect an
 obfs3|tcp client (obfs3 with a tcp listener shim) with any old obfs3
 relay.

 So we need a way for:
  * clients to say, "these are the transport chains I support, and the
 address I'm listening on for each one."
  * proxies to say, "these are the outer transports I support."
  * the facilitator to know a static list of relays, with their transport
 chains and the listening address for each.

 First I propose to deprecate the existing `client=` notation and make it
 synonymous with `client-websocket=`.

 Let's consider the use case of a client that supports websocket,
 obfs3|websocket, and obfs3|tcp. It may send a registration message like,
 {{{
 client-websocket=1.2.3.4:1000&client-obfs3%7cwebsocket=1.2.3.4:2000
 &client-obfs3%7ctcp=1.2.3.4:3000
 }}}
 Proxies send some information in their GET request. (Currently just a
 protocol revision number and a list of clients, see
 [https://gitweb.torproject.org/flashproxy.git/blob/a5cdc109d0dd2bf0b09c6453b58dd848cae608bd:/proxy/flashproxy.js#l567
 here].) So the proxy might send its list of supported transports:
 {{{
 GET /r=1&transport=websocket&transport=webrtc HTTP/1.1
 }}}
 Then the facilitator needs to find a client and a relay where 1) the
 components in the transport chain are the same up to the last component,
 and 2) the last component is websocket or webrtc. Let's say it finds an
 obfs3|websocket relay at 10.10.10.10:9902. Then it can send a reply to the
 proxy:
 {{{
 client-obfs3%7cwebsocket=1.2.3.4:2000&relay-
 obfs3%7cwebsocket=10.10.10.10:9902
 }}}

 Embedding the transport chain in the "name" part of application/x-www-
 form-urlencoded name-value pairs is kind of an abuse, but it's not too
 bad. Perhaps there is a better way to do it. I originally used
 application/x-www-form-urlencoded because it was already implemented in
 JavaScript. If I were starting over, I would probably use JSON as there
 are standard functions to parse JSON in browsers and lots of other
 languages support it.

 I think, because of the "outermost transport" thing, that we will have to
 specify transport chains as parseable strings (for instance using the pipe
 notation I used above), and not opaque identifiers like "obfs3_flash" or
 "obfs-in-websocket".

 I agree a config file to specify a list of known relays and their
 transports is a good idea.

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