On 2012-02-29, Arturo Filastò hellais@torproject.org wrote:
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.
The SOCKS 5 spec permits all of those characters. (I know this because I found a bug related to embedded NULs in Tor's SOCKS 5 server and stream-isolation code.) If we design our spec to not allow managed transports to support special characters, someone somewhere someday will block all Tor managed transports in one fell swoop by forcing all traffic through a SOCKS proxy that requires one of those characters in its passwords.
(Since this is a discussion about a proposal, not a final spec, “I would just take a look at their solution.” is a valid answer for now. But the spec we implement *must* specify an actual solution to this problem.)
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.
I know how the user specifies an HTTP proxy to Tor. How does Tor specify an HTTP proxy to a managed transport?
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.
Tor cannot change a managed transport's environment variables after the managed transport has been started.
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.
A managed transport should not attempt to connect to the network before it finishes printing the information Tor expects it to print to stdout.
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.
If Tor ‘exit[s] with error’ when it reads a PROXY-ERROR line, then all errors which are communicated to Tor using PROXY-ERROR lines are fatal errors.
A user-configured proxy server being unreachable or rejecting a username and/or password is not an acceptable reason to end the Tor process (thereby preventing the user from changing the broken configuration using Vidalia).
Robert Ransom