[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:  needs_revision
 Priority:  normal                       |      Milestone:                
Component:  Pluggable transport          |        Version:                
 Keywords:  SponsorF20131101 flashproxy  |         Parent:                
   Points:                               |   Actualpoints:                
-----------------------------------------+----------------------------------

Comment(by dcf):

 Replying to [comment:28 asn]:
 > looking at the logic of `obfs-flash.git`, it seems that if we want a
 bundle that contains `websocket`, `obfs2|websocket` and `obfs3|websocket`,
 then we will have to spawn 3 `flashproxy-client`s and each one of them
 will do its own registration.
 >
 > That's fine, but each of those `flashproxy-client`s should be aware of
 the transport chain it supports, so that it can submit a proper client
 registraton to the facilitator.
 >
 > How should we do this? Should we add a CLI swich to `flashproxy-client`
 that looks like this: `--transport=websocket|obfs3`? Should we also be
 able to specify a default port for that transport so that we can ask
 people to forward a specific TCP port (like we currently do with
 `DEFAULT_REMOTE_PORT`)?

 Yeah, I like the `--transport` option. Although in this case I think it
 would be `--transport=obfs3|websocket` (opposite order to match earlier
 discussion). The default transport would be `websocket`. You have to add
 the option to all the registration helpers too (`flashproxy-reg-email`
 etc.). See `build_register_command` in `flashproxy-client`.

 Knowledge of default ports should be built into the super-proxy, not
 `flashproxy-client`, I think. What I am imagining is a configuration file
 that shows what commands to run for the sub-proxies. `flashproxy-client`
 takes its remote port from the command line like this. The super-proxy
 will inform `flashproxy-client` of its remote port, and then `flashproxy-
 client` forwards that port to the registration helpers.

 If #5426 were done, then the super-proxy could do registration, rather
 than `flashproxy-client` doing it.

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