[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 infinity0):

 I should be less hasty claiming "proofs", there are like a million ways of
 doing this. My diagram above was actually different from all the solutions
 in asn's previous post; here are the corresponding diagrams for each.
 Importantly, we always need a shim between flashproxy and obfsproxy,
 simply because their input/output interfaces are incompatible (one is
 SOCKS, the other isn't) - I've called it super_m.

 "a) Make both |flashproxy| and |obfsproxy| Extended ORPort listeners,"

 :D=flash(OU)|flash-s|P=SOCKS(OU),Q=control(D): ->
 :P=SOCKS(OU),Q|super_m|R=OU,Q'=Q: ->
 :R=obfs(U),Q'|modified obfs-s|S=SOCKS(U),T=Q': ->
 :S=SOCKS(U),T=control(D)|tor-s|Tor(U):

 (Actually, |flash-s| doesn't need to be a listener, in this case.)

 "b) Implement yet-another-metadata protocol for this use case."

 :D=flash(OU)|super_1|E=flash(ODU): ->  # where ODU == obfs(D+U), D+U being
 the "custom protocol". Note, this is slightly different from the one I
 drew above, but is similar in intent.
 :E=flash(ODU)|flash-s|P=SOCKS(ODU),Q=control(E): ->
 :P=SOCKS(ODU),Q|super_m|R=ODU: ->
 :R=obfs(D+U)|obfs-s|S=SOCKS(D+U),T=control(R): ->
 :S=SOCKS(D+U),T|super_2|S'=SOCKS(U),T'=control(D): ->
 :S'=SOCKS(U),T'=control(D)|tor-s|Tor(U):

 "c) Have |super_2| bind to different local ports to denote different
 clients."

 This is just a variation of (b) where super_1 can somehow (outside of the
 diagram) dynamically change the port that |obfs-s| connects to.

 "d) Put client IPs in a queue inside |super| and when |super_2|
 connects to the Extended ORPort pop the queue and report that
 IP. "

 Sounds like incorrect behaviour to me...?

 Solution (a) seems the cleanest and re-usable, because of the way the
 general transport plugin architecture works. If we are to have arbitrary
 composable plugins, the easiest way is to require them to be an Extended
 ORPort listener, and passthrough data appropriately. This could be added
 to a library to make things easier for developers.

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