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

 We had a discussion about this project with David and Ximin. We decided
 that we will probably build a super-proxy that chains PTs together.

 So the topology for the client-side will look like this:

 |tor client| -> ( |obfsproxy| -> |flashproxy| ) -> |INTERNET|

 where the parentheses is the super-proxy.

 The topology on the server-side is similar:

 |internet| -> ( |flashproxy| -> |obfsproxy| ) -> |Extended ORPort|

 ----

 We've been having some problems with the server-side, since
 |obfsproxy| is no longer aware of the client's IP address, and can't
 report it using the Extended ORPort.

 This means that the super-proxy is probably going to do the Extended
 ORPort handshake, since it's the entity who knows the IP address of
 the client (it also knows the name of the combined pluggable transport
 used).

 Thinking about it like this:

 |internet| -> |super_1| -> |flashproxy| -> |obfsproxy| -> |super_2| ->
 |Extended ORPort|

 the question now becomes:

 "How does |super_2| match up the connections it receives from
 |obfsproxy| with the connections received in |super_1|?"

 We have a few options. Unfortunately, all of them seem ugly.

 a) Make both |flashproxy| and |obfsproxy| Extended ORPort listeners,
 and chain up Extended ORPort connections.

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

 So for example, |super_1| prepends the client IP to the traffic
 flow (with a delimiter) and both |flashproxy| and |obfsproxy| pass
 it on to |super_2| who does the Extended ORport connection with the
 info.

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

 So for example, when |super_1| receives connection X, it asks the
 transport proxies to forward this connection to a specific port
 number that |super_2| binds to. This way |super_2| knows that data
 received to that port is from connection X. Different connections
 use different ports.

 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. Of course, this doesn't guarantee that client IPs will match
 with the correct data :) Tor doesn't care about this currently, but
 it might in the future.

 The above solutions are hacky or/and cheap or/and evil.
 What other solutions exist?

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