obfsproxy: Use server-side transport parameters

A client-side obfsproxy can get transport parameters by using the SOCKS handshake username/password fields.

On the server-side obfsroxy should use the scheme from #8929 (moved) to get the transport parameters. Also, after using them, obfsproxy should send the parameters that must be advertised in the extra-info descriptor using the ARGS option in the SMETHOD line.

added component::pyobfsproxy owner::asn priority::medium resolution::fixed status::closed type::task labels

Note to self: A gentleman from SIF13 wrote some code for this issue. You can find his code at branch bug8979 in https://gitweb.torproject.org/user/asn/obfsproxy.git. It might need some more work to be purfect.

Steps for completion of this ticket:

• Make pyptlib parse the TOR_PT_SERVER_TRANSPORT_PARAMETERS environment variable, and return it to the transport. Also, make pyptlib send the ARGS option in its SMETHOD lines.

• Make obfsproxy get the parameters from pyptlib and pass it to the correct transport. obfsproxy currently gets info from pyptlib in managed/server.py using the managed_info variable. That info should somehow reach the transports (preferably in a clean way), so that transports can configure their shared-secrets etc.

• Obfsproxy transports should be able to select some of those parameters and send them back to tor (using the SMETHOD line and ARGS) so that they can be sent to BridgeDB. SMETHOD lines are currently sent in managed/server.py using the pyptlib reportSuccess function.

asn and I just discussed this in #tor-dev. In principle, there are two options:

1. We can just blindly pass all transport parameters to BridgeDB. This would be the easiest solution. If pluggable transports expect "secret" information which BridgeDB should not know (such as directory paths), then the transports could provide a dedicated config file rather than let this information pass through Tor/pyptlib/obfsproxy. Note that right now we don't have a transport which wants secret information.
2. Instead of blindly forwarding parameters to BridgeDB, we could sanitize them first and remove "secret" parameters. There are two ways how this could be done:
3. pyptlib could forward the parameters to the pluggable transport which then tells pyptlib which parameters are safe to publish. This would probably require nontrivial changes to pyptlib/obfsproxy.
4. The "Bridge" line in the torrc could somehow encode which parameters are safe to publish and which are not. This would requiring changing #8929 but could be easier to implement than the first option.

OK. Pushed initial branches for this feature.

For pyptlib, please check branch bug8979 in https://git.torproject.org/user/asn/pyptlib.git. For obfsproxy, please check branch bug8979_draft in https://git.torproject.org/user/asn/obfsproxy.git.

A typical bridge torrc configuration would look like this:

ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --log-min-severity=debug --log-file=/home/user/serverobfs.log managed
ServerTransportOptions obfs2 shared-secret=banana

A typical client torrc configuration is:

Bridge obfs2 127.0.0.1:38073 shared-secret=banana
ClientTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --log-min-severity=debug --log-file=/home/user/clientobfs.log managed

Please test and enjoy responsibly.

For the constructor-based approach in obfsproxy, please check branch bug8979_constructor in https://git.torproject.org/user/asn/obfsproxy.git.

Trac:
Status: new to needs_review

Replying to asn:

For the constructor-based approach in obfsproxy, please check branch bug8979_constructor in https://git.torproject.org/user/asn/obfsproxy.git.

Tested and works for me. Thanks!

Merged. Thanks for testing!

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #9406 (closed)

mentioned in issue #9815 (closed)