[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):
I think the idea of a transport chain needs work. I don't believe what has
been said so far is precisely coherent:
- the browser proxy communicates to client and server via TCP channels,
*regardless of the contents*. Having "tcp" as a valid transport name like
"obfs|tcp" doesn't make sense. "" (empty string) would be the appropriate
name for the transport chain that carries raw user data.
- I also don't understand this whole "outermost transport" thing, since
the browser proxy just passes bytes and doesn't need to speak the
outermost transport in order to do this.
- However, in order to *match* client vs server, it needs to match the
entire chain. a client that speaks "obfs|websocket" isn't going to be able
to talk to a server that speaks "xxx|websocket"
Here is my understanding:
Certain types of PTs are what I'll call a "byte-transform" PT - i.e. at
its heart, it transforms input bytes to some output bytes, and the
underlying transport *mechanism* (TCP in this case) is undisturbed.
obfsproxy is a "byte-transform" PT, but flashproxy isn't, since it does
extra stuff to the underlying channel, so that the output of flashproxy
cannot by fed into a "byte-transform" PT.
A transport chain only makes sense if each component in the chain is a
byte-transform PT. A browser proxy can pass the data stream transparently,
or it can strip off layers in order to adapt between client/servers:
- a client of a|b|c can talk to a server a|b|c and the proxy doesn't need
to do anything, just pass bytes
- a client of a|b|c can talk to a server a|d|e but the proxy needs to
apply the transformation e(d(b-inv(c-inv(_)))) to the data stream from the
client, and vice-versa from the server. (This is essentially what
[comment:12 arlolra] did in his "raw tcp" commit.)
(A more general framework generalises the idea of a "byte-transform" PT -
each PT has an *input* interface, and an *output* interface, then you can
chain PTs by matching input interfaces to output interfaces. But we can
stick with byte-to-byte PTs for now.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9349#comment:22>
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