[tor-bugs] #9744 [Pluggable transport]: Read managed proxy server chain from a configuration file

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#9744: Read managed proxy server chain from a configuration file
---------------------------------+---------------------
 Reporter:  dcf                  |          Owner:  asn
     Type:  project              |         Status:  new
 Priority:  normal               |      Milestone:
Component:  Pluggable transport  |        Version:
 Keywords:  flashproxy           |  Actual Points:
Parent ID:                       |         Points:
---------------------------------+---------------------
 The server in #7167 is called obfs-flash, but it is not inherently tied to
 obfsproxy not flash proxy. The only things obfs and flash about it are
 that it hardcodes commands to run obfsproxy and websocket-server. So let's
 generalize it with a configuration file. This is what I envision:
 {{{
 ServerTransportPlugin obfs3 exec obfsproxy managed
 ServerTransportPlugin websocket exec websocket-server
 Alias obfs3_websocket obfs3|websocket
 }}}
 What this configuration file means is, "Here is how you run the obfs3
 transport, here is how you run the websocket transport, and if Tor asks
 you for the transport obfs3_websocket, this is the chain you should
 interpret it as."

 The idea of using the keyword `ServerTransportPlugin` is so that you can
 copy a transport configuration from a `torrc` or from the transport's
 README--but it is not meant to be a general `torrc` parser; in particular,
 `ServerTransportPlugin ... proxy` won't be allowed. The `Alias` is because
 tor doesn't allow the pipe character in transport names; it will become
 unnecessary if #9580 is implemented.

 The above proxy configuration would go along with a `torrc` like this. I'm
 using the name meta-proxy-server for what is now called obfs-flash-server.
 {{{
 ServerTransportPlugin obfs3_websocket exec meta-proxy-server
 }}}

 Having an external configuration file is nice, because it allows you to
 for example add `--log` options to the commands, without recompiling the
 meta-proxy.

 Imagine a bigger configuration:
 {{{
 ServerTransportPlugin rot13 exec myrot13server --managed
 ServerTransportPlugin chaffer exec chaffer-server
 ServerTransportPlugin obfs2,obfs3 exec obfsproxy managed
 ServerTransportPlugin websocket exec websocket-server
 Alias rot13_websocket rot13|websocket
 Alias obfs2_websocket obfs2|websocket
 Alias obfs3_websocket obfs3|websocket
 Alias chaffedobfs3 chaffer|obfs3
 }}}
 With its accompanying `torrc`:
 {{{
 ServerTransportPlugin obfs2_websocket,obfs3_websocket,chaffedobfs3 exec
 meta-proxy-server
 }}}
 You can imagine the chaffer transport, for example, as being something
 that changes packet sizes and timings. Then you could chain it into obfs3
 to make obfs3 less fingerprintable. You could even do dumb things like
 obfs3-in-obfs3-in-websocket.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9744>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs