[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9349 [Flashproxy]: flashproxy facilitator: Allow clients to specify transports
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs