On Feb 28, 2012, at 5:38 PM, Robert Ransom wrote:
On 2012-02-29, Arturo Filastò hellais@torproject.org wrote:
When Tor is configured to use both a Pluggable Transport proxy and SOCKS proxy it should delegate the proxying to the pluggable transport proxy.
This can be achieved by setting the environment variables for the SOCKS proxy to that specified inside of the torrc.
When the pluggable transport proxy starts it will first read the environment variables and if it detects that it should be using a SOCKS proxy make all it's traffic go through it. Once the pluggable transport proxy has successfully established a connection to the SOCKS proxy it should notify Tor of it's success or failure. When both the SOCKS and the PluggableTransport directives are set Tor should set the environemnt variable start the pluggabletransport proxy and wait for it to report back on the SOCKS proxy status. If the pluggable transport reports back a failure or it does not report back at all (maybe because it is an outdated version), Tor should notify the user of the failure and exit with an error.
That's not very nice. At a minimum, Vidalia users will never be able to use the GUI to recover from setting such a configuration. (Users can put Tor into such a configuration using the GUI, by configuring Tor to use a proxy while a managed transport which does not support one is specified in the torrc.)
Specifications: Tor Pluggable Transport communication
When Tor detects a SOCKS proxy directive and a Pluggable Transport proxy directive it sets the environment variable:
"TOR_PT_PROXY" -- This is the address of the proxy to be used by the pluggable transport proxy. It is in the format: <proxy_type>://<user_name?>:<password?>@<ip>:<port> ex. socks5://tor:test1234@198.51.100.1:8000 socks4a://198.51.100.2:8001
What does Tor send if a SOCKS username or password contains ':', '@', or '\0'?
Well I think no username and password should contain that characters, especially the last. If that is not the case I am sure an approach to deal with this problem has been found by many others in the past. I would just take a look at their solution.
How does Tor specify an HTTP proxy?
HTTPProxy host[:port] Tor will make all its directory requests through this host:port (or host:80 if port is not specified), rather than connecting directly to any directory servers.
How does Tor specify an HTTP/HTTPS proxy (i.e. an HTTP proxy which supports the CONNECT method)?
HTTPSProxy host[:port] Tor will make all its OR (SSL) connections through this host:port (or host:443 if port is not specified), via HTTP CONNECT rather than connecting directly to servers. You may want to set FascistFirewall to restrict the set of ports you might try to connect to, if your HTTPS proxy only allows connecting to certain ports.
How does Tor pass proxy settings to a managed transport after it has started? (If it can't, then you'll have to either (a) break all OR connections through that transport by stopping and restarting it or (b) remember to not use that instance of the transport again, and launch and start using another instance of the same transport for new OR connections with the same managed transport specified. (a) is easier to implement, but not nice.)
via the environment variable TOR_PT_PROXY. This means of communication is documented inside of proposal 180.
If the pluggable transport proxy detects that the TOR_PT_PROXY environment variable is set it attempts connecting to it. On successs it will write to stdout (as specified in 180-pluggable-transport.txt) PROXY true. On failure it should write PROXY-ERROR <errormessage>.
What kinds of failures lead to a PROXY-ERROR response?
That the proxy server in unreachable, that the authentication has failed for example.
If Tor does not read any PROXY line or it reads a PROXY-ERROR line and it is configured to use both SOCKS and PluggableTransport it should exit with error.
Are managed transports not permitted to report to Tor that they have had a non-fatal error while attempting to connect to a proxy?
Yes that is what is done with PROXY-ERROR. This means of communication between Tor and pluggable transports is documented better inside of proposal 180.
- Art.