Yawning Angel yawning@schwanenlied.me writes:
Hello all,
To address bug #10671: "Pluggable Transports: Improve method of transferring parameters to client-side transports", I submit the enclosed proposal for consideration.
Very nice!
A few comments below.
--- Begin proposal body ---
Filename: xxx-pt-socks5-extensions.txt Title: Pluggable transport SOCKS5 extensions Author: Yawning Angel Created: 25-Feb-2014 Status: Draft
Abstract
We propose extending the SOCKS5 protocol when communicating with pluggable
<snip>
The pluggable transport verifies the supplied Username, Password, and Extended Data and sends the following response:
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Status | +---------------+---------------+ Version: 8 bits (unsigned integer) This field specifies the version of the authentication method. 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?
Status: 8 bits (unsigned integer) This field specifies the status of the authentication request. A Status of X'00' indicates 'success'. If the pluggable transport returns a 'failure' (Status value other than X'00'), it MUST close the connection.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.
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.
Where:
* X'F0' Temporary failure, retry immediately Pluggable transports SHOULD return this status code if the connection attempt failed, but the pluggable transport believes that subsequent connections with the same parameters are likely to succeed. Example: The ScrambleSuit Session Ticket handshake failed, but reconnecting is likely to succeed as it will use the UniformDH handshake. * X'F1' Pluggable transport protocol failure, invalid bridge Pluggable transports MUST return this status code if the connection attempt failed in a manner that indicates that the remote peer is not likely to accept connections at a later time. Example: The obfs3 handshake failed. * X'F2' Pluggable transport internal error Pluggable transports SHOULD return this status code if the connection attempt failed due to an internal error in the pluggable transport implementation. Tor might wish to restart the pluggable transport executable, or retry after a delay.