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

[Yawning Angel]

On Tue, 25 Feb 2014 19:42:51 +0000
George Kadianakis <desnacked at riseup.net> wrote:

> >     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?

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,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140225/aa73ef2c/attachment-0001.sig>