Opened 7 years ago

Closed 7 years ago

#8979 closed task (fixed)

obfsproxy: Use server-side transport parameters

Reported by: asn Owned by: asn
Priority: Medium Milestone:
Component: pyobfsproxy Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


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 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.

Child Tickets

Change History (7)

comment:1 Changed 7 years ago by asn

Note to self: A gentleman from SIF13 wrote some code for this issue. You can find his code at branch bug8979 in It might need some more work to be purfect.

comment:2 Changed 7 years ago by asn

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/ 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/ using the pyptlib reportSuccess function.
Last edited 7 years ago by asn (previous) (diff)

comment:3 Changed 7 years ago by phw

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:
    1. 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.
    2. 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.

comment:4 Changed 7 years ago by asn

OK. Pushed initial branches for this feature.

For pyptlib, please check branch bug8979 in
For obfsproxy, please check branch bug8979_draft in

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 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.

comment:5 Changed 7 years ago by asn

Status: newneeds_review

For the constructor-based approach in obfsproxy, please check branch bug8979_constructor in

comment:6 in reply to:  5 Changed 7 years ago by phw

Replying to asn:

For the constructor-based approach in obfsproxy, please check branch bug8979_constructor in

Tested and works for me. Thanks!

comment:7 Changed 7 years ago by asn

Resolution: fixed
Status: needs_reviewclosed

Merged. Thanks for testing!

Note: See TracTickets for help on using tickets.