#9744 closed project (fixed)
Read managed proxy server chain from a configuration file
Reported by: | dcf | Owned by: | asn |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Circumvention/Pluggable transport | Version: | |
Severity: | Keywords: | flashproxy fog | |
Cc: | asn, infinity0 | Actual Points: | |
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
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.
Child Tickets
Attachments (1)
Change History (8)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
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.
comment:3 Changed 6 years ago by
Changed 6 years ago by
Attachment: | server-superproxy.jpg added |
---|
Sketch of how the obfs-flash server super-proxy work
comment:4 Changed 6 years ago by
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.
comment:5 Changed 6 years ago by
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
comment:6 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Looks like Quinn did this for fog in 58858475e5ba737ca0e7e271b7604fe1ac06bf75.
comment:7 Changed 5 years ago by
Keywords: | fog added |
---|
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