[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 am new here so am still trying to form a mental model to reason about
 this system. Here's what I have so far, let me know if it's correct and/or
 useful.

 For preciseness, I am going to state, explicitly, the IN-interface and
 OUT-interface of each component. (This will also help with any general
 plugin-composition framework later on.) For example, this is what a
 typical normal Tor channel, without transport plugins, looks like:

 :SOCKS(U)|tor-c|A=Tor(U):  ->
 :A=Tor(U)|tor-s|B=Tor(U):  ->
 :B=Tor(U)|tor-s|C=Tor(U):  ->
 :C=Tor(U)|tor-s|U:

 where A=X means a channel A using protocol X, and X(U) means something
 that wraps U. A could be e.g. a inet socket, or a file descriptor, or some
 combination of these. To chain stuff correctly, we must ensure the OUT-
 interface of one component matches the IN-interface of the next component.
 (Technically we should write Z=SOCKS(U), D=U for the first,last
 components, but since we're not using Z,D anywhere I'll just leave them
 out.)

 With a general transport plugin, the diagram from the client to the server
 is:

 :SOCKS(U)|tor-c|A=SOCKS(U):  ->
 :A=SOCKS(U)|plugin-c|X(U):  ->
 :X(U)|plugin-s|P=SOCKS(U),D=control(X):  ->
 :P=SOCKS(U),D=control(X)|tor-s|Tor(U):

 For obfsproxy:

 :SOCKS(U)|tor-c|A=SOCKS(U):  ->
 :A=SOCKS(U)|obfs-c|B=obfs(U):  ->
 :B=obfs(U)|obfs-s|P=SOCKS(U),Q=control(B):  ->
 :P=SOCKS(U),Q=control(B)|tor-s|Tor(U):

 For flashproxy:

 :SOCKS(U)|tor-c|A=SOCKS(U):  ->
 :A=SOCKS(U)|flash-c|B=flash(U):  ->
 :B=flash(U)|flash-s|P=SOCKS(U),Q=control(B):  ->
 :P=SOCKS(U),Q=control(B)|tor-s|Tor(U):

 For obfs-flash-proxy, then, an incomplete "first attempt" using naiving
 layering:

 :SOCKS(U)|tor-c|A=SOCKS(U):  ->
 :A=SOCKS(U)|obfs-c|B=obfs(U):  ->
 :B=OU|super|C=SOCKS(OU):  ->  # where OU == obfs(U)
 :C=SOCKS(OU)|flash-c|D=flash(OU):  ->
 :D=flash(OU)|flash-s|P=SOCKS(OU),Q=control(D):  ->
 ??
 :R=obfs(U)|obfs-s|S=Tor(U),T=control(R):  ->
 :S=SOCKS(U),T=control(R)|tor-s|Tor(U):

 So we have two problems here:
 - how to implement ?? - we need a component that reads input from an OUT-
 interface of {SOCKS(X),control(D)}, and writes output to an IN-interface
 of {X}.
 - as written, using this naive layering architecture, we have no way of
 connecting the control(D) channel to something. what we really want to do
 is turn the T=control(R) into a T=control(D), since the former is an
 implementation detail and the latter is the user-originated data that we
 need to actually control.

 I'll need some more time working out the precise details, but a quick read
 gives me the impression that the super_1/super_2 solution proposed above
 solves these two problems by re-architecting the OU that passes through
 the |flash-s| component into something like OU+D.

 Does this make sense, am I correct, and/or did I go overboard with the
 notation? :p

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