[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:  new
 Priority:  normal                       |      Milestone:     
Component:  Pluggable transport          |        Version:     
 Keywords:  SponsorF20131101 flashproxy  |         Parent:     
   Points:                               |   Actualpoints:     
-----------------------------------------+----------------------------------

Comment(by asn):

 I started looking into integrating flashproxy within obfsproxy.
 Unfortunately, the obfsproxy architecture is quite conservative (pure
 client/server model, client opens SOCKS server, client listens on
 upstream, server listens on downstream, focuses on traffic obfuscation),
 whereas flashproxy is much more avant-garde (both client and server
 listens on downstream, focuses on IP address obfuscation not on traffic
 obfuscation, etc.).
 This means that integrating flashproxy in obfsproxy will require a big
 refactoring, which will not necessarily be helpful in the future when
 integrating other PTs. For example, looking at #7153 it seems that the
 suggested changes are hand-tailored for specific PTs, without having big
 reusable value.

 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?

 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.)

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