[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'm also between (a) and (b). (c) seems a bit hacky and might be painful
 to reproduce bugs, debug, etc.

 For both (a) and (b) we will probably have to add another mode (let's call
 it `super_server` for now) to our transports, so that their server-side
 listener acts like an Extended ORPort (or another metadata protocol). We
 will also have to change the pt-spec so that we can suggest that mode to
 our transports using the managed-proxy configuration protocol.

 I suspect that a light variant of (b) might be easier to implement than
 (a):
 `|internet| -> |super_1| -> |flashproxy| -> |obfsproxy| -> |super_2| ->
 |Extended ORPort|`
 For example, for every connection that `super_1` receives, it prepends
 `<ip>:<super-transport>:DELIMITERDELIMITERDELIMITERDELIMITER` to the
 traffic flow and passes it on to flashproxy. Then `flashproxy` and
 `obfsproxy`, when in `super_server` mode, are instructed to ignore the
 first chunk of data of the connection (up until
 `DELIMITERDELIMITERDELIMITERDELIMITER`). When `super_2` receives that
 first chunk, it parses it, gets the relevant information and removes it
 from the traffic flow. It then does an Extended ORPort client connection
 to Tor.

 The above idea is not entirely elegant but it might be easier to implement
 than (a).

 (a) is more future-proof but might be messy when the Extended ORPort
 authentication part comes into the game. We will have to find a place to
 store the Extended ORPort auth cookies, and also find a name format that
 will allow the other transport proxies to find the correct cookie for each
 Extended ORPort.

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