pyobfsproxy should use a proxy if tor so desires

When trying to configure a proxy and a set of bridges in Vidalia, the user will get a message saying "Unacceptable option value: You have configured more than one proxy type.".

added component::pyobfsproxy flashproxy owner::chiiph priority::medium resolution::invalid status::closed type::defect labels

Trac:

This seems to be a tor issue. Even if the error message makes sense, the idea was to distribute the obfsproxy bundle with the ClientTransportPlugin line hardcoded, and then the user could add Bridge lines or not without worrying about the ClientTransportPlugin line. This seemed fine at first, but now it seems to mean that those users won't be able to configure other proxies.

Is this something we could handle in the tor side somehow?

Trac:
Cc: N/A to asn
Component: Vidalia to Tor Client

I don't know if there is a plan to make Tor work with both a normal proxy server and obfsproxy bridges. I wonder if a good solution for now is to have Vidalia give the user a sane error message saying that the user will have to use normal bridge instead.

asn and I talked about this and decided it's probably an obfsproxy missing feature: it doesn't know how to send its traffic through a proxy.

It's a low priority feature for obfsproxy though, and once it's in Tor is going to need to know how to add Tor's proxy settings to the obfsproxy command line, so Runa's point is a good one that we might want to make Vidalia explain that it won't work. Perhaps that's greying out the proxy choice in Vidalia if ClientTransportPlugin is set? That might be harmful later though if later client transport plugins do handle a proxy setting. Hm.

Trac:
Cc: asn to chiiph
Component: Tor Client to Obfsproxy

How about the possibility of Tor ignoring the ClientTransportPlugin if there are no obfs bridges? This would solve the "lets distribute bundles with the ClientTransportPlugin line hardcoded".

The other question would be: how would I be able to detect this particular failure case? or: how can I recognize pluggable transport bridges in a generic way? Right now Vidalia just troughs tor the bridge lines as-is exactly because of the parsing issue. I could look for "ClientTransportPlugin" and "Proxy" from the error message to recognize this particular case, but it doesn't seem like the best way to go.

Seems like the real fix is to teach obfsproxy how to use upstream proxies. Otherwise, people who require a proxy for access, but that proxy blocks tor by protocol, won't be able to use it. (Currently a simple upstream proxy to block tor completely is one that allows connections to dns names only, for example). This is getting complex...

Replying to arma:

asn and I talked about this and decided it's probably an obfsproxy missing feature: it doesn't know how to send its traffic through a proxy.

It's a low priority feature for obfsproxy though, and once it's in Tor is going to need to know how to add Tor's proxy settings to the obfsproxy command line,

You can't put upstream proxy settings on a pluggable transport's command line because the user might set them after Tor has started its pluggable transports. Every pluggable transport needs to have a two-way control connection open with Tor at all times.

So the consensus is that we will live with this issue for now, but the fix should happen in tor/obfsproxy/documentation for new transports.

How will a documentation fix help here tho if you need an upstream proxy to connect to the internet?

It will help for future transports so they know what tor will expect from them. In this case, tor will eventually tell the transport about the proxy and we may find other things that the transport should support too.

Arturo wrote a proposal on how tor should notify obfsproxy that the user wants to pipe traffic through a SOCKS proxy: https://lists.torproject.org/pipermail/tor-dev/2012-February/003318.html

Trac:
Summary: Vidalia says "Unacceptable option value" when setting both proxy and bridges to obfsproxy should use a SOCKS proxy if tor so desires

Actually, this should not be restricted to SOCKS proxies. Arturo's proposal can be used for any kind of proxy (including HTTP).

Trac:
Summary: obfsproxy should use a SOCKS proxy if tor so desires to obfsproxy should use a proxy if tor so desires

I'll pivot this ticket to 'pyobfsproxy'.

Trac:
Component: Obfsproxy to pyobfsproxy
Summary: obfsproxy should use a proxy if tor so desires to pyobfsproxy should use a proxy if tor so desires

Trac:
Keywords: N/A deleted, flashproxy added
Cc: chiiph to chiiph, dcf@torproject.org

Here I added support to tell obfsproxy to connect via a socks proxy: https://github.com/hellais/obfsproxy.

Trac:
Status: new to needs_review

Closing this one since it was related to "pyobfpsroxy".

The obfspoxy-side of #8402 (moved) is at #8956 (closed).

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

closed

mentioned in issue #5602 (moved)

mentioned in issue #8402 (moved)

mentioned in issue #11535 (closed)