Opened 6 years ago

Closed 4 years ago

#5195 closed defect (invalid)

pyobfsproxy should use a proxy if tor so desires

Reported by: runa Owned by: chiiph
Priority: Medium Milestone:
Component: pyobfsproxy Version:
Severity: Keywords: flashproxy
Cc: chiiph, dcf@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Attachments (1)

vidalia-proxy-bridges.jpg (130.1 KB) - added by runa 6 years ago.

Download all attachments as: .zip

Change History (16)

Changed 6 years ago by runa

Attachment: vidalia-proxy-bridges.jpg added

comment:1 Changed 6 years ago by chiiph

Cc: asn added
Component: VidaliaTor Client

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?

comment:2 Changed 6 years ago by runa

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.

comment:3 Changed 6 years ago by arma

Cc: chiiph added; asn removed
Component: Tor ClientObfsproxy

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.

comment:4 Changed 6 years ago by chiiph

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.

comment:5 Changed 6 years ago by Sebastian

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

comment:6 in reply to:  3 Changed 6 years ago by rransom

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.

comment:7 Changed 6 years ago by chiiph

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.

comment:8 Changed 6 years ago by Sebastian

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

comment:9 Changed 6 years ago by chiiph

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.

comment:10 Changed 6 years ago by asn

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

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

comment:11 Changed 6 years ago by asn

Summary: obfsproxy should use a SOCKS proxy if tor so desiresobfsproxy should use a 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).

comment:12 Changed 5 years ago by asn

Component: Obfsproxypyobfsproxy
Summary: obfsproxy should use a proxy if tor so desirespyobfsproxy should use a proxy if tor so desires

I'll pivot this ticket to 'pyobfsproxy'.

comment:13 Changed 5 years ago by dcf

Cc: dcf@… added
Keywords: flashproxy added

comment:14 Changed 5 years ago by hellais

Status: newneeds_review

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

comment:15 Changed 4 years ago by asn

Resolution: invalid
Status: needs_reviewclosed

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

The obfspoxy-side of #8402 is at #8956.

Note: See TracTickets for help on using tickets.