[tor-bugs] #7167 [Pluggable transport]: Combine traffic obfuscation with address diversity of flash proxy

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Jul 16 00:54:28 UTC 2013


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

 Summary from IRC today: we decided to try to implement (d) first because
 it's the simplest, even though it's only correct when certain assumptions
 hold, about how Tor actually uses the metadata/headers from the ORPort
 protocol.

 Additionally, I have another variant which I was trying to communicate on
 IRC earlier, but I'm not sure if I did a good job of it. I don't think
 it's much more complex than (d), and is fully correct without relying on
 the above assumptions. It mixes ideas from (a) and (c), using different
 ports to distinguish between clients, in order to avoid both using a new
 custom protocol (as in (b)), or requiring obfsproxy to be modified to
 accept ORPort (as in (a)).

 To recap, for (c) we need to somehow "tell" obfsproxy to send its output
 to different ports. One way to achieve this is to start a new instance of
 obfsproxy for each client connection, telling it to listen on a different
 port. To avoid having to start a new instance of flashproxy too, we move
 the |super_1| component *after* it. So the diagram looks like this:

 |flashproxy| -> |super_1| -> |obfsproxy| -> |super_2| -> |Tor|

 1. super_1 reads ORPort from flashproxy, stores all headers (COMMANDS
 using terminology of spec 196) and associates this info with some random
 port P
 2. super_1 tells super_2 to listen on port P (can do this in-process)
 3. super_1 opens a new instance of obfsproxy, with its ORPort set to P.
 4. super_1 sends BODY to obfsproxy
 5. obfsproxy processes this and sends ORPort output to super_2, on port P.
 6. super_2 reads ORPort from obfsproxy on port P, looks up the headers
 associated with P and sends these to Tor
 7. super_2 skips the headers from the incoming channel (since they are
 from obfsproxy and not flashproxy), then forwards BODYLEN/BODY directly
 onto Tor

 In summary, super_1 receives extended ORPort protocol, and outputs raw
 data; super_2 receives and outputs extended ORPort protocol.

 Advantages:
 - super_1/super_2 do not need to know what flashproxy/obfsproxy do -
 (except, super_1 needs to know how to start up obfsproxy, but any super-
 proxy must know this info)
 - flashproxy/obfsproxy do not need to be changed

 Disadvantages:
 - a new obfsproxy process is created for each client connection.

 Things not considered:
 - ORPort authentication
 - TransportControlPort

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


More information about the tor-bugs mailing list