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

[Tor Bug Tracker & Wiki]

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

 Replying to [comment:27 dcf]:
 > Replying to [comment:23 infinity0]:
 > > And if I understood correctly, a raw TCP-TCP proxy can proxy anything
 *including* a obfs|websocket stream, assuming that it's valid to cut out
 the middle man in our websocket transport.
 >
 > This is not true, for perhaps a subtle reason. You may be thinking of
 the flashproxy client as being a WebSocket client talking to a WebSocket
 server--but that is not the case. Both the flashproxy client and the Tor
 relay are WebSocket ''servers'', and the proxy is a client in both
 directions. Yes, if a proxy is just tunnelling bytes, a client acting as a
 WebSocket client could tunnel through the proxy and talk to a WebSocket
 server, but that's not how the model works. These outermost transports are
 always client–server in the proxy–client and proxy–relay directions.
 >
 > The transport on the outside means "the proxy has to be able to
 establish this kind of connection." A proxy that can open a TCP connection
 doesn't necessarily have code to establish a WebSocket connection. Not to
 mention that WebRTC is UDP-based; a TCP proxy can't tunnel just
 ''anything''. I think it makes sense to leave "tcp" explicit for this
 reason; it means the proxy has to be capable of making a normal TCP
 connection. After all, something like obfs3|sctp might make a lot of
 sense.
 >
 > What you said would be true if a flash proxy worked like an ordinary
 proxy, receiving a connection from a client and forwarding it to the
 server. But a flash proxy uses a connect-back model.
 >

 Ok, understood.

 > > So what really matters, is not the "outermost layer", but a "suffix
 constraint" for each proxy, which must be matched against the full
 transport chain.
 >
 > What you say here is true, but for the sake of simplicity I want to
 deliberately ignore full generality and insist that the proxy speak only
 the outermost layer.

 In this case, I think we ought to reconsider the chaining syntax, and
 probably stop using term "chain" at all. They strongly suggest an abstract
 model which is not consistent with the model you're proposing - which
 would be just a prefix/suffix pair model.

 The prefix/suffix ought to be opaque strings such that the separation is
 *unambiguous* (as opposed to a chain "a|b|c" where it's ambiguous where to
 split it into two). Then the matching algorithm remains as I described in
 the above post, but it's much easier to implement since each client/server
 transport has exactly one possible prefix-suffix separation.

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