[tor-dev] [draft]: Proposal xxx: Pluggable transport SOCKS5 extensions

[George Kadianakis]

Yawning Angel <yawning at 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
>
> 0. 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.