Comments on proposal idea xxx-pluggable-transport
nickm at freehaven.net
Wed Jan 19 19:38:23 UTC 2011
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
> 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.
More information about the tor-dev