Comments on proposal idea xxx-pluggable-transport

[Nick Mathewson]

On Sat, Jan 15, 2011 at 9:04 PM, Steven J. Murdoch
<tor+Steven.Murdoch at cl.cam.ac.uk> wrote:
 [...]
> Currently this code isn't compliant with the xxx-pluggable-transport
> proposal, but in thinking about it, I have had a few thoughts.
>
> 1) The proposal talks about SOCKS, and my code implements SOCKS4.
> However from my reading, the proposal depends on SOCKS5 because it
> talks about putting NUL-separated key/value pairs in the username and
> password fields of the SOCKS handshake. SOCKS4 there is no password
> field and the username is NUL terminated, so NUL characters are not
> permitted inside.
>
> We could mandate that protocol obfuscators support SOCKS5 (it's not
> much harder to implement than SOCKS4), or change the spec to not
> require NULs in the username field. Either way it doesn't make a big
> difference but it should be clear which version of SOCKS we are
> talking about.

Good catch.  Tor can currently speak socks4 or socks5, so I would
suggest having the choice of socks protocol be up to the transport.
Instead of NUL-separated parameters, we can pick some other
non-printing separator (0x01, for instance), or we could move to a
K=V;K=V;K=V format so long as we provide a way to escape any ; bytes
that occur in the V portions.  Suggestions?

Whatever encoding we pick, we should pick one that works just as well
for socks4 or socks5, so that we don't need to implement two versions
of it.

> 2) The syntax for specifying obfuscated access to bridges is:
>
>  bridge method address:port [[keyid=]id-fingerprint] [k=v] [k=v] [k=v]
>
> This could be a bit confusing considering the current syntax (which we
> will have to keep for backwards compatibility:
>
>  bridge address:port [fingerprint]
>
> If we require that method does not contain a ":" and a port is always
> specified, I can see how this could be unambiguously parsed, but that
> seems a bit ugly.

We could require that a method be a valid C identifier.  Any other
suggestions for making it less ugly?

> 3) The two options for specifying a transport are:
>
>  ClientTransportPlugin trebuchet socks5 127.0.0.1:9999
>
>  ClientTransportPlugin trebuchet /usr/libexec/tor-proxies/trebuchet [options]
>
> These seem ambiguous. How can Tor reliably tell that the first form is
> intended when both could have the same number of arguments?

Hm.  I had assumed that all programs would be specified by an absolute
path, but you're right that it's ambiguous as-is. How about instead
the second syntax becomes:

ClientTransportPlugin trebuchet program /usr/libexec/tor-proxies/trebuchet.

?

> 4) When Tor launches the client proxy, the client proxy decides what
> port it is listening on. This raises the possibility of conflicts. How
> about if Tor picks the ports the client proxy should listen on, and
> tells it via a command line parameter. Note that this can't be simply
> the first parameter, because on Windows (where scripts are not
> executable) the user would have to specify the path as
> C:/Python/python.exe SCRIPTNAME.py.

How do you see the conflict arising?  I'd assume that any decent
client proxy should try a few possible ports until it gets one that
works... or just bind to port 0, and have the kernel pick.

> 5) Minor. Methods are specified as "CMETHOD: methodname", but
> terminated with "METHODS:DONE". I think we should be consistent about
> whether there is a space between the colon and value.

Agreed; let's have a space.

-- 
Nick