Read managed proxy server chain from a configuration file

[dcf]

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.

[infinity0]

The concept of chaining needs further work to be coherent. In particular, the current obfs-flash-client isn't able to cope with arbitrary chains.

Any near-future feasible chaining framework must restrict the outgoing interface of a PT, for all PTs in the chain except the last one. Currently, pt-spec.txt only restricts the incoming interface of a PT.

I have some diagrams here and will write up more notes to explain the diagrams soon:

​https://github.com/infinity0/tor-notes/blob/master/pt-compose.rst

[dcf]

Let's keep this ticket about the server transport. I agree that on the client it is a bit more complicated, but on the server everything is very straightforward and I want to keep it that way.

[dcf]

I like those diagrams above. Here is how the obfs-flash server works.

[dcf]

Sketch of how the obfs-flash server super-proxy work

[dcf]

I edited the server so that it starts the chain using a generic loop that doesn't have obfs3 and websocket hardcoded, and added a ​getConfiguration function that acts as though it had read the configuration file from the description. Adding a real config file parser is all it takes to turn the obfs-flash server into a fog server.

[dcf]

I ​augmented obfs-flash to enable setting transport options per-transport. getConfiguration can now return an options map and it will be given appropriately to transport binaries.

A configuration file with options might look like

ServerTransportPlugin obfs3 exec obfsproxy managed
ServerTransportPlugin websocket exec websocket-server
ServerTransportOptions obfs3 shared-secret=foobar
Alias obfs3_websocket obfs3|websocket

[dcf]

Looks like Quinn did this for fog in ​58858475e5ba737ca0e7e271b7604fe1ac06bf75.