On Sat, Jan 15, 2011 at 9:04 PM, Steven J. Murdoch <[email protected]> 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
