On Tue, 25 Feb 2014 19:42:51 +0000 George Kadianakis <desnacked@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev