obfsproxy should use a SOCKS proxy if Tor wants it to

This is the obfsproxy side of #8402 (moved).

hellais prepared a patch for obfsproxy that can be found here: https://github.com/hellais/obfsproxy/commits/socks_client

added component::archived/obfsproxy owner::asn parent::8402 priority::medium resolution::fixed status::closed type::task labels

See ​https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-pluggable-transports-through-proxy.txt for the latest version of the tor proposal.

Trac:
Cc: N/A to yawning

pyptlib changes to support this: https://github.com/yawning/pyptlib/tree/bug_8402

The patch by hellais won't apply cleanly because I changed a lot of the obfsproxy SOCKS code, so I will work on integrating that next, along with also allowing use of HTTP CONNECT proxies.

obfsproxy changes to support this: https://github.com/Yawning/obfsproxy/tree/bug_8956

The bulk of the credit goes to hellais, I just updated it to use my pyptlib changes and the new SOCKS5 code. Next up, HTTP CONNECT, then on to patching tor.

Replying to yawning:

pyptlib changes to support this: https://github.com/yawning/pyptlib/tree/bug_8402

The patch by hellais won't apply cleanly because I changed a lot of the obfsproxy SOCKS code, so I will work on integrating that next, along with also allowing use of HTTP CONNECT proxies.

Excellent.

A small review. I can do the changes myself before merging if you are bored, no worries.

• I try to mention the trac ticket numbers in the ChangeLog.
• I'm quite happy that urlparse.urlsplit can parse our format. It would be great though if there was some kind of documentation on what getProxy() returns, so that users of the library can use it appropriately.

Nice unittests!

Trac:
Status: new to needs_revision

Trac:
Component: pyobfsproxy to Obfsproxy

Replying to yawning:

obfsproxy changes to support this: https://github.com/Yawning/obfsproxy/tree/bug_8956

The bulk of the credit goes to hellais, I just updated it to use my pyptlib changes and the new SOCKS5 code. Next up, HTTP CONNECT, then on to patching tor.

How do you feel about bug8956_tweak in my repo? It kills settings.py and moves the state-keeping to TransportConfig. I think that makes more sense, since we've been using TransportConfig for similar reasons anyway.

While doing so, I removed the functionality of having both --proxy and managed mode. I did so because it simplified code (the TransportConfig in managed mode is created way after CLI parsing), and also because it seems like a not very useful feature (the managed-proxy protocol should be instructing obfsproxy to use a proxy, not the CLI).

I haven't tested my branch yet.

Note to self: Yawning says that the --proxy option might be useful even in managed mode, in case the TBB team decides to use --proxy till #8402 (moved) gets merged and deployed.

FWIW, I'm currently waiting for HTTP support before merging.

FYI, I moved my branches for all of this into my user repos (bug_8402 pyptlib branch and bug8956_tweak obfsproxy branch).

The pyptlib changes that you requested are done as commit 99a33bf1751b953c4e488bff6b2303ccaa80dacb. Please feel free to adjust the docstring as appropriate, I don't know the correct syntax.

The refactor you did had a minor bug, fixed in 58326981ebfa2fbfffa76a1880e7bfec4633301f. HTTP CONNECT is done in 2477925050651940a40741b2c12910bb36250594.

Trac:
Status: needs_revision to needs_review

pyptlib and obfsproxy work fine for me. Both with SOCKS proxy (obfsproxy with socks using dummy transport) and an HTTP proxy (privoxy).

Another small fix for my commit can be found in my bug8956_tweak.

I went and cleaned up the error handling slightly per our discussion, see commit a79b8ae6a147fdebc59e6555ad5e985487c47f94.

It turns out that Twisted doesn't have a custom exception type for EHOSTUNREACH in twisted.internet.error, so it generates a failure with ConnectError. I put code in to distinguish that case and send the proper SOCKS5 error back as an added bonus, yay for a slightly more informative Tor log (The case when the proxy just abruptly closes the connection, users will still need to look at the obfsproxy log though).

Unless you want to re-add support for --proxy in managed mode (which would make this more immediately usable to people), I think that just about wraps up all the code for this feature.

Merged in obfsproxy!

Thank you very much for the hard work!

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

Also see #11535 (closed).

closed

mentioned in issue #10234 (closed)

mentioned in issue #11409 (closed)