Comments on proposal idea xxx-pluggable-transport

[Steven J. Murdoch]

I've been working on some code to make it more difficult for someone
observing traffic between a Tor client and bridge to know that it is
Tor traffic (and therefore blocking it). It works by making the
traffic look more like HTTP, but it would be desirable to have other
alternative transports. Making this work easily is the topic of
xxx-pluggable-transport:

 https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/proposals/ideas/xxx-pluggable-transport.txt

My code for sending Tor over (not quite) HTTP can be found here:

 http://gitweb.torproject.org/sjm217/pluggable-transport.git

It is far from being HTTP compliant, but is good enough to make
Wireshark think it is HTTP, and it shouldn't have any static strings
which make it easy to block (as it implements a very simple
repeating-pad xor obfuscation of underlying Tor data).

 http://www.cl.cam.ac.uk/~sjm217/volatile/pluggable-transport.png

N.B. This code runs, but it is trivially recognizable by someone who
knows what they are doing. It might get through an automated firewall
that blocks Tor, but please don't use it in situations where users
would be at risk of recriminations if they are caught using this
software.

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.

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.

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?

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.

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.

Steven.

-- 
http://www.cl.cam.ac.uk/users/sjm217/