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

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Sep 18 06:40:14 UTC 2013


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

Comment (by dcf):

 Replying to [comment:14 asn]:
 > Also pushed trivial flashproxy modifications in branch
 `bug9349_proxy_side`.
 {{{
 +        params.push(["transports", "websocket"]);
 }}}
 I think I prefer `transport` here, not `transports`. If there are multiple
 transports I want the query string to look like
 {{{
 transport=websocket&transport=webrtc
 }}}
 not
 {{{
 transports=websocket,webrtc
 }}}
 so that we don't have to invent our own format for list serialization, and
 concomitant worries about escaping within URL escaping. To use such a
 multiple-valued query string is easy, for example you can use Python's
 [http://docs.python.org/2/library/cgi.html#cgi.FieldStorage.getlist
 FieldStorage.getlist].

 Likewise in facilitator transactions, I would like to see multiple
 `TRANSPORT=` instead of one `TRANSPORTS=`. You will have to add a new
 function in `fac.py` that is like `param_first` but it returns the whole
 list of values.
 {{{
 +    transports = transport_list.join(",") # XXX wtf
      try:
 -        command, params = transact(f, "GET", ("FROM",
 format_addr(proxy_addr)))
 +        command, params = transact(f, "GET", ("FROM",
 format_addr(proxy_addr)), ("TRANSPORTS", transports))
 }}}

 In the facilitator, let's break backward compatibility and redefine the
 `-r` option to be the name of the relay file to load.

 Let's use a tuple to represent a transport chain internally--parse it with
 `str.split("|")` as soon as it's read, and format it with `"|".join` only
 just before output. Then `get_outermost_transport(chain)` is just
 `chain[-1]`.

 `options.relays` should be indexed not by complete transport chains, but
 by transport chains excluding their last element. It should be possible
 for an obfs3|websocket client to talk to an obfs3|tcp relay, if there is a
 proxy that speaks both websocket and tcp. To be specific you should key by
 the tuple `("obfs3",)` and not `("obfs3", "websocket")`.

 I don't want to make a distinction between "new-style" and "old-style"
 registrations. There is just one backward-compatible style. In your loop
 over `fs.keys()`, notice a key that is exactly `client`, and treat it the
 same as `client-websocket`.

 I'm also hoping you will address the client comments from comment:10.

 My plan for merging is to first do the proxy, because that's trivial and
 doesn't require other changes, then merge the facilitator. We can then run
 client registrations manually to test obfs-flash.

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


More information about the tor-bugs mailing list