On Tue, 25 Feb 2014 19:42:51 +0000 George Kadianakis desnacked@riseup.net wrote:
Version: 8 bits (unsigned integer) This field specifies the version of the authenticationmethod. It MUST be set to X'01'.
How is the client-side version field supposed to be used? For example, if the client doesn't support the version that the server proposed, is it supposed to fail with a non-zero Status value, and set the Version to the version it supports (doesn't sound like a great idea tbh)?
Or is it always supposed to be the same version that the server proposed?
The latter. The client sends a version field as part of the request, the server either echos it in the response, or drops the connection (unsupported auth version).
2.2. Tor Pluggable Transport SOCKS5 Reply Codes
We introduce the following additional SOCKS5 reply codes to be sent in the REP field of a SOCKS5 reply message.
Hm, this looks like a useful feature but requires some engineering effort.
For example, with the current obfsproxy/Twisted codebase, obfsproxy receives the SOCKS request, connect()s to the destination, and if the connect succeeds it sends a positive SOCKS reply to the SOCKS server. Then, only when obfsproxy has received the first application-layer data from Tor, it performs the scramblesuit/obfs3 handshake.
So with the current codebase, obfsproxy wouldn't know whether to send 'F0' back to the server at the time of the SOCKS handshake. Changing this would be possible but it would require a few changes in the Twisted and obfsproxy networking logic.
*nods*. All of that code has to be touched when obfsproxy gets a SOCKS5 listener anyway, so I don't see that as being a huge blocker.
For the record, obfsclient delays sending a SOCKS5 response till after the handshake succeeds. I personally view sending a successful SOCKS5 reply to indicate to the client (tor) that "If you send data, it will get relayed", which isn't necessarily the case in the current obfsproxy model as you described it. obfsproxy's behavior probably should be changed to sending the response post handshake regardless.
Also, the transport author would have to know whether an error is retryable or not, and raise the appropriate exception (or something).
I wonder if we have enough use cases for the 'F0' return value to make this worth implementing.
Perhaps not now, but moving forward, I think differentiating between "the connection failed because of transient reasons" vs "The bridge is invalid/your connection is getting MITMed/etc" is important.
For ScrambleSuit, with a deferred SOCSK5 response it's also possible to hold the SOCKS5 connection open if the Session Ticket handshake fails, and reopen the outgoing connection and try UniformDH, but I believe that would require more code than "send back a different response code and let tor decide what to do".
Thanks,