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

[Tor Bug Tracker & Wiki]

#7167: Combine traffic obfuscation with address diversity of flash proxy
-----------------------------------------+----------------------------------
 Reporter:  karsten                      |          Owner:  asn         
     Type:  project                      |         Status:  needs_review
 Priority:  normal                       |      Milestone:              
Component:  Pluggable transport          |        Version:              
 Keywords:  SponsorF20131101 flashproxy  |         Parent:              
   Points:                               |   Actualpoints:              
-----------------------------------------+----------------------------------
Changes (by dcf):

  * status:  new => needs_review


Comment:

 I wrote a simple implementation of obfs3-in-flashproxy. It's just two
 shell scripts tying the various programs together. It is even simpler than
 [comment:8 option (d)] above--it doesn't handle ExtORPort. But it works
 and boostraps--I was using IRC through it today.
 {{{
 git clone https://www.bamsoftware.com/git/obfs-flash.git
 }}}
 The scripts are less than 100 lines together, which I hope shows that at
 least the basic mechanics of chaining transports aren't that difficult. I
 call this implementation "Mk. I," with the idea that Mk. II will be (d)
 and Mk. III will be one that correctly handles the ordering of streams
 that connect back to the super-proxy.

 The server component `obfs-flash-server` is running at
 tor1.bamsoftware.com:9500 (173.255.221.44:9500). To run the client part,
 use the included `torrc`:
 {{{
 tor -f torrc
 }}}
 Wait a few seconds, then open a non-Tor browser running a local flash
 proxy:
 http://crypto.stanford.edu/flashproxy/embed.html?debug&client=127.0.0.1:9000&relay=173.255.221.44:9500
 Remember to wait 60 seconds after 50% bootstrapping. You don't need to do
 any port forwarding.

 One thing we didn't think about was the flash proxy facilitator. The
 reason you have to run your own flash proxy in the instructions above is
 that the facilitator doesn't know that it needs to give a obfs3-in-
 websocket relay to proxies that are serving certain clients. Obviously
 connecting to the plain websocket relay that the facilitator uses now,
 won't work. We need to think of a way to allow a client to say that it
 wants to connect to a different kind of relay. Like client registration
 messages, which currently only contain the client IP and port, could also
 contain the nested protocols the client wants to use. The facilitator
 would check to see if it knows of any relays having that nesting, and
 reply to proxies with an appropriate relay. I have some previous thinking
 along these lines in comment:2:ticket:5578, comment:5:ticket:7944.

 The next easiest step, I think, is to do a Python reimplementation of the
 client side. It will do proper parsing (and error reporting) of PT stdout
 output, and remove the need for an external socat program.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7167#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online