[tor-bugs] #7167 [Pluggable transport]: Combine traffic obfuscation with address diversity of flash proxy

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Jun 14 18:32:10 UTC 2013


#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


More information about the tor-bugs mailing list