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

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

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

 Replying to [comment:16 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))
 > }}}
 >

 Fixed both comments above.

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

 Done. I did not know how to update the init script though.

 > 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]`.
 >

 Done.

 > `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")`.
 >

 Not yet done.

 > 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`.
 >

 Done.

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

 Not yet done.

 > 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.

 I pushed the facilitator changes in `bug9349_server_side_draft`.
 I pushed the flashproxy changes (s/transports/transport) to
 `bug9349_proxy_second_take`.

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