[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7167 [Pluggable transport]: Combine traffic obfuscation with address diversity of flash proxy
#7167: Combine traffic obfuscation with address diversity of flash proxy
-----------------------------------------+----------------------------------
Reporter: karsten | Owner: asn
Type: project | Status: new
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Keywords: SponsorF20131101 flashproxy | Parent:
Points: | Actualpoints:
-----------------------------------------+----------------------------------
Comment(by dcf):
Replying to [comment:6 asn]:
> When I communicated my thoughts to David, we brainstormed on something
between ideas b) and c) of comment:2. That is, maybe we shouldn't try to
integrate both PTs into one, but we should find a nice way to use them
both at the same time. For example, from the PoV of obfsproxy, flashproxy
should just be a magic socket that transports the bytes to the correct
location. And from the PoV of flashproxy, obfsproxy should just be a magic
obfuscator that encodes/decodes bytes. That is, we are moving to a more
layered approach, which I think is a good way to think of and develop
network protocols.
>
> Some things to think about:
> a) How should we pass bytes between obfsproxy and flashproxy? Should it
be SOCKS chaining, or just pipe bytes from one program to another?
SOCKS chaining is probably where we need to go in the future. Perhaps
easier is to strip out the SOCKS handler from `flashproxy-client` and
configure obfsproxy to connect directly to `flashproxy-client`'s `LOCAL`
port. (See the `flashproxy-client` man page; `LOCAL` normally receives
SOCKS from Tor; `REMOTE` receives WebSocket from the Internet.)
{{{
flashproxy-client --external --no-socks --register :11111 :9000
obfsproxy obfs3 socks 127.0.0.1:22222
}}}
Then configure Tor to connect to the client transport at 127.0.0.1:22222
and make a SOCKS request for 127.0.0.1:11111.
> b) Who should manage these two programs? In the original post of this
ticket, it was suggested that Tor would manage those two programs. Another
approach would be to have obfsproxy spawn and manage flashproxy. Without
thinking much about it, I think the latter approach is also worth
considering, since managing subprocesses in Python is probably easier than
in C, and furthermore Tor would never need to learn about this (obfsproxy
would just expose a new transport name (e.g. obfsflashproxy) that would do
the obfsproxy+flashproxy combination internally.)
I think we want a third program (say obfs-flash-proxy) that controls both
flashproxy and obfsproxy parts. Tor will call obfs-flash-proxy as if that
program were implementing the entire transport itself. obfs-flash-proxy
will fork the other two programs and connect them however necessary.
{{{
Bridge obfs-flash 0.0.1.0:1
ClientTransportPlugin obfs-flash exec ./obfs-flash-proxy
}}}
As for how to provide command-line options to the flashproxy and obfsproxy
parts, well, hmm, I dunno yet.
Also, for the server transport, we have no SOCKS or anything, and so have
to do something different. Maybe ExtORPort chaining? Or give up on the
extended ORPort and just do ORPort chaining of server transports, which
will be really easy.
This is obviously not fully general, but in the interest of meeting
deadlines perhaps it shouldn't be. It is simple enough that it will
clearly work, and it gives us something to compare a more general
framework against in the future. "Do the simplest thing that could
possibly work" etc.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7167#comment:7>
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