[tor-dev] Pluggable Transport through SOCKS proxy

[Robert Ransom]

On 2012-02-29, Arturo Filastò <hellais at torproject.org> wrote:
> On Feb 28, 2012, at 5:38 PM, Robert Ransom wrote:
>
>> On 2012-02-29, Arturo Filastò <hellais at 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 at 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