Tor should help its transport proxy use a proxy, if needed.

If a censored user wants to use both a (normal) proxy and a pluggable transport proxy, Tor should psas the credentials of the (normal) proxy to the pluggable transport proxy.

The proxy chain should look like this: Tor (Client) -> Transport Proxy (Client) -> SOCKS/HTTP Proxy -> Internet -> Transport Proxy (Server) -> Tor (Bridge)

Arturo prepared a related proposal in: https://lists.torproject.org/pipermail/tor-dev/2012-February/003318.html We should clean it up, see if anything is missing, and start implementing it in Tor.

changed milestone to %Tor: 0.2.6.x-final

added 026-triaged-1 component::core tor/tor flashproxy milestone::Tor: 0.2.6.x-final priority::high pt resolution::implemented status::closed tbb-helpdesk-frequent tbb-needs tbb-tor-backported-3.6.1 tor-bridge type::defect labels

Trac:
Cc: N/A to dcf@torproject.org
Keywords: tor-bridge pt deleted, tor-bridge pt flashproxy added

See https://blog.torproject.org/blog/pluggable-transports-bundles-2417-beta-2-pt3-firefox-1709esr#comment-36500 for a recent case of this bug impacting users.

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:
Parent: #5195 (closed) to N/A

Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.6.x-final

Trac:
Cc: dcf@torproject.org to dcf@torproject.org, yawning

meek-client is capable of using an upstream HTTP proxy (since here), but you have to set it up manually, either with a command-line option

Bridge meek 0.0.2.0:1
ClientTransportPlugin meek exec ./meek-client --url=http://meek.bamsoftware.com:7002/ --http-proxy=http://127.0.0.1:8787/

or with a bridge line arg

Bridge meek 0.0.2.0:1 url=http://meek.bamsoftware.com:7002/ http-proxy=http://127.0.0.1:8787
ClientTransportPlugin meek exec ./meek-client

I looked into implementing support for this and do not believe it will be difficult, but I think the proposal requires PT_MANAGED_TRANSPORT_VER bump.

My rationale for this is when it is necessary for users to use a SOCKS proxy (in a heavily censored enviornment for instance), tor should fail without attempting to send traffic over the network instead of attempting a direct connection that will fail, and possibly bring the wrath of the IT department (or whatever) down on the user.

Unless the version is bumped up, pyptlib/liballium will ignore this portion of the config protocol.

Thoughts? (Also if we are going to bump the version, are there any other things like this that should go into version 2 of the pt config protocol?)

Replying to yawning:

I looked into implementing support for this and do not believe it will be difficult, but I think the proposal requires PT_MANAGED_TRANSPORT_VER bump.

That's not necessarily so. We could add a client stdout message that means "I have understood and will obey your proxy request," and tor could avoid sending anything through the PT until it gets that message.

Well, that's what bumping the version would do.

I was thinking along the lines of "tor could only attempt to negotiate the v2 protocol if any of the various *Proxy options are set in the torrc". That may get messy in the future, but I'm not sure about how much more will get added to the PT spec, so it's hard to figure out what would be better.

A ha, I'm blind, sorry.

If the pluggable transport proxy detects that the TOR_PT_PROXY environment variable is set, it attempts connecting to it. On success it writes to stdout: "PROXY true". On failure it writes: "PROXY-ERROR ".

So dcf's variant of this is already in the proposal. I'm not sure if attempting to connect to it is required (Would it be ok to just spit out "PROXY true" to acknowledge that it will use the proxy?), as that is potentially identifiable behaviour, but I don't have any other issues with the design and will probably look into adding this to pyptlib/liballium and adding support for this to obfsproxy.

Trac:
0001-Allow-ClientTransportPlugins-to-use-proxies.patch

Patch to implement the tor side of things

A patch against tor master that adds this functionality. The only pluggable transport currently capable of using it is my obfsproxy branch linked of #8956 (closed).

I'm not sure what is supposed to happen if the user edits the torrc to specify a different proxy (eg changing from nothing to SOCKS5, or SOCKS5 to HTTPS). The existing code probably won't detect this as something worthy of restarting all the pluggable transports, so I think I need to add code to detect this in or/transports.c/proxy_needs_restart(), along with caching the previously configured proxy settings.

Trac:
Status: new to needs_revision

Trac:
0001-Allow-ClientTransportPlugins-to-use-proxies_ver2.patch

Version 2 of the patch that supports SIGHUP

Trac:
Status: needs_revision to needs_review

Nice!

A few comments from a preliminary review. I would like to review it once again:

• As we discussed in IRC, unit tests for the non-trivial additions would be great.

• Maybe we could functionify the new duplicate code in get_proxy_addrport(). I know that Nick hates duplicate code, and I share his sentiments.

• This is more of a comment to the original proposal, but isn't PROXY true a bit off in a protocol that doesn't have any other false/true strings? Maybe PROXY DONE is more appropriate? Maybe not.

• acked_proxy is a bit of a deceiving name. Maybe we should change the variable name to imply some connection to the proxy?

Other than that, patch looks very promising!