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

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Sep 20 08:00:57 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: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.

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

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


More information about the tor-bugs mailing list