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/
