[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