[draft]: Proposal xxx: Pluggable transport SOCKS5 extensions
Hello all, To address bug #10671: "Pluggable Transports: Improve method of transferring parameters to client-side transports", I submit the enclosed proposal for consideration. --- 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 transports to allow passing more per-bridge meta-data to the transport and returning more meaningful connection failure response codes back to Tor. 1. Introduction To allow for more sophisticated pluggable transports, it would be useful to support more than 510 bytes of per-connection data, while using the SOCKS5 pluggable transport interface. Additionally as pluggable transports increase in sophistication, it is useful for the pluggable transport to be able to return well defined errors back to Tor if the connection establishment fails. 2. Proposal 2.1. Tor Pluggable Transport Username/Password Authentication We introduce a new authentication method to the SOCKS5 protocol based on the existing RFC 1929 Username/Password Authentication that pluggable SHOULD support. The METHOD number to be returned to indicate support for or select this method is X'80', which belongs to the "RESERVED FOR PRIVATE METHODS" range in RFC 1928. After the authentication method has been negotiated following the standard SOCKS5 protocol, the actual authentication phase begins. Tor will send a Username/Password/Extended Data request: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Username Len | +---------------+---------------+ \ Username \ / ... / \ (Username Len bytes) \ +---------------+---------------+ | Password Len | \ +---------------+ / \ Password \ / ... / \ (Password Len bytes) \ +---------------+---------------+ | Extended Data Len | +---------------+---------------+ \ Extended Data \ / ... / \ (Extended Data Len bytes) \ +---------------+---------------+ Version: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. Username Len: 8 bits (unsigned integer) This field specifies the length of the Username field in bytes. It MAY be X'00', in which case the Username field is omitted. Username: variable length, optional The Username to use when authenticating. Password Len: 8 bits (unsigned integer) This field specifies the length of the Password field in bytes. It MAY be X'00', in which case the Password field is omitted. Password: variable length, optional The Password to use when authenticating. Extended Data Len: 16 bits (unsigned integer) This field specifies the length of the Extended Data field in bytes. It MAY be X'0000', in which case the Extended Data field is omitted. The Extended Data Len field MUST be transmitted in network byte order. 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'. 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. 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. 3. Compatibility SOCKS5 negotiates authentication methods so backward and forward compatibility is obtained for free, assuming a non-broken SOCKS5 implementation in the pluggable transport side that ignores unrecognised authentication methods in the negotiation phase. The extended status codes are informative clarifications of a failure state, so existing Tor binaries will continue existing behavior for a general failure. 4. Security Considerations Identical security considerations to RFC 1929 Username/Password authentication applies. As the Username/Password fields are carried in cleartext, this authentication method MUST NOT be used in scenarios where sniffing is possible. The authors of this proposal note that pluggable transports bind to the loopback address, so in the current model this is believed to be acceptable. 5. Open Questions Is 65535 bytes of per-bridge/per-connection data sufficient? Pluggable transports currently have no notion of authentication due to the Username/Password fields of the RFC 1929 authentication method being hijacked to convey extended data. Is this a feature that will be implemented in the future? 6. References Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., Jones L., "SOCKS Protocol Version 5", RFC 1928, March 1996. Leech, M. "Username/Password Authentication for SOCKS V5", RFC 1929, March 1996. Appelbaum, J., Mathewson, N., "Pluggable Transport Specification", June 2012. --- End proposal body --- Questions, comments, feedback appreciated. -- Yawning Angel
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
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.
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 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
Il 2/25/14, 11:15 AM, Yawning Angel ha scritto:
Hello all,
To address bug #10671: "Pluggable Transports: Improve method of transferring parameters to client-side transports", I submit the enclosed proposal for consideration. Please consider integrating within SOCKS protocol related extension proposals also the ones needes by Tor2web described at https://trac.torproject.org/projects/tor/ticket/6031
-- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org
On Tue, 25 Feb 2014 22:30:06 +0100 "Fabio Pietrosanti (naif)" <lists@infosecurity.ch> wrote:
Il 2/25/14, 11:15 AM, Yawning Angel ha scritto:
Hello all,
To address bug #10671: "Pluggable Transports: Improve method of transferring parameters to client-side transports", I submit the enclosed proposal for consideration.
Please consider integrating within SOCKS protocol related extension proposals also the ones needes by Tor2web described at https://trac.torproject.org/projects/tor/ticket/6031
Skimming the ticket, it looks like the extensions discussed there are orthogonal to what this proposal is aimed at. To be specific, this proposal is aimed at the SOCKS server that is run in a pluggable transport binary (obfsproxy, obfsclient, and others), with tor acting as the SOCKS client. While there may be other possible uses for the extended authentication mechanism or response codes (In particular, it could be useful for the Tor Browser to pass out of band data on a per connection basis to Tor), use in such contexts should probably be discussed separately, as design considerations that apply when we do not control and define both the client and server side of the link start to apply. Regards, -- Yawning Angel
Hello all, Based on feedback from nickm/arma, I have extended the proposal to also cover Tor's SOCKS port, including response codes related to hidden service status. Additionally, instead of having a username/password field pre-defined, the extended authentication method has been generalized to contain key/value pairs for extra flexibility in the future. Questions, comments, feedback appreciated as always, -- Yawning Angel --- Begin proposal body --- Filename: xxx-further-socks5-extensions.txt Title: Further SOCKS5 extensions Author: Yawning Angel Created: 25-Feb-2014 Status: Draft 0. Abstract We propose extending the SOCKS5 protocol to allow passing more per-session metadata, and to allow returning more meaningful reponse failure codes back to the client. 1. Introduction The SOCKS5 protocol is used by Tor both as the primary interface for applications to transfer data, and as the interface by which Tor communicates with pluggable transport implementations. While the current specifications allow for passing a limited amount of per-session metadata via hijacking the Username/Password authentication method fields, this solution is limited in that the amount of payload that can be conveyed is restricted to 510 bytes, does not allow the SOCKS server to return a response, and precludes using authentication on the SOCKS port. The first part of this proposal defines a new authentication method to overcome both of these limitations. The second part of this proposal defines a range of SOCKS5 response codes that can be used to signal Tor specific error conditions when processing SOCKS requests. 2. Proposal 2.1. Tor Extended SOCKS5 Authentication We introduce a new authentication method to the SOCKS5 protocol. The METHOD number to be returned to indicate support for or select this method is X'97', which belongs to the "RESERVED FOR PRIVATE METHODS" range in RFC 1928. After the authentication method has been negotiated following the standard SOCKS5 protocol, the actual authentication phase begins. The initiator will send an Extended Authentication request: +----+----------+-------+-------------+-------+-------------+--- |VER | NR PAIRS | KLEN1 | KEY1 | VLEN1 | VALUE1 | ... +----+----------+-------+-------------+-------+-------------+--- | 1 | 2 | 2 | KLEN1 bytes | 2 | VLEN1 bytes | ... +----+----------+-------+-------------+-------+-------------+--- VER: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. NR PAIRS: 16 bits (unsigned integer) This field specifies the number of key/value pairs to follow. The NR PAIRS field MUST be transmitted in network byte order. KLEN: 16 bits (unsigned integer) This field specifies the length of the key in bytes. It MUST be transmitted in network byte order, and MUST be greater than 0. KEY: variable length This field contains the key associated with the subsequent VALUE field as an ASCII string, without a NULL terminator. VLEN: 16 bits (unsigned integer) This field specifies the length of the value in bytes. It MUST be tramsmitted in network byte order. It MAY be X'0000', in which case the corresponding VALUE field is omitted. VALUE: variable length, optional The value corresponding to the KEY. The responder will verify the contents of the Extended Authentication request and send the followint response: +----+--------+----------+-------+-------------+-------+-------------+--- |VER | STATUS | NR PAIRS | KLEN1 | KEY1 | VLEN1 | VALUE1 | ... +----+--------+----------+-------+-------------+-------+-------------+--- | 1 | 1 | 2 | 2 | KLEN1 bytes | 2 | VLEN1 bytes | ... +----+--------+----------+-------+-------------+-------+-------------+--- VER: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. STATUS: 8 bits (unsigned integer) The status of the Extended Authentication request where: * X'00' SUCCESS * X'01' AUTHENTICATION FAILED * X'02' INVALID ARGUMENTS If a server sends a response indicating failure (STATUS value other than X'00') it MUST close the connection. NR PAIRS: 16 bits (unsigned integer) This field specifies the number of key/value pairs to follow. The NR PAIRS field MUST be transmitted in network byte order. KLEN: 16 bits (unsigned integer) This field specifies the length of the key in bytes. It MUST be transmitted in network byte order, and MUST be greater than 0. KEY: variable length This field contains the key associated with the subsequent VALUE field as an ASCII string, without a NULL terminator. VLEN: 16 bits (unsigned integer) This field specifies the length of the value in bytes. It MUST be tramsmitted in network byte order. It MAY be X'0000', in which case the corresponding VALUE field is omitted. VALUE: variable length, optional The value corresponding to the KEY. The currently defined KEYs are: * "UNAME" The username for authentication. * "PASSWD" The password for authentication. [XXX - Add some more here, Stream isolation?] 2.2. Tor Extended SOCKS5 Reply Codes We introduce the following additional SOCKS5 reply codes to be sent in the REP field of a SOCKS5 message. Implementations MUST NOT send any of the extended codes unless the initiator has indicated that it understands the "Tor Extended SOCKS5 Authentication" as part of the version identifier/method selection SOCKS5 message. Where: * X'E0' Hidden Service Not Found The requested Tor Hidden Service was not reachable. * X'E1' Hidden Service Not Reachable The requested Tor Hidden Service was not found. * X'F0' Temporary Pluggable Transport 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. 3. Compatibility SOCKS5 negotiates authentication methods so backward and forward compatibility is obtained for free, assuming a non-broken SOCKS5 implementation on the responder side that ignores unrecognised authentication methods in the negotiation phase. 4. Security Considerations Identical security considerations to RFC 1929 Username/Password authentication applies when doing Username/Password authentication using the keys reserved for such. As the UNAME/PASSWD fields are carried in cleartext, this authentication method MUST NOT be used in scenarios where sniffing is possible. The authors of this proposal note that binding any of the Tor (and associated) SOCKS5 servers to non-loopback interfaces is strongly discouraged currently, so in the current model this is believed to be acceptable. 5. References Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., Jones L., "SOCKS Protocol Version 5", RFC 1928, March 1996. Tor Project, "Tor's extensions to the SOCKS protocol" Leech, M. "Username/Password Authentication for SOCKS V5", RFC 1929, March 1996. Appelbaum, J., Mathewson, N., "Pluggable Transport Specification", June 2012. [XXX - Changelog (Remove when accepted)] 2014-02-28 (Thanks to nickm/arma) * Generalize to also support tor * Add status codes for bug #6031 * Switch from always having a username/password field to making them just predefined keys. * Change the auth method number to 0x97 --- End proposal body ---
28.02.2014 09:53, Yawning Angel:
2.2. Tor Extended SOCKS5 Reply Codes
We introduce the following additional SOCKS5 reply codes to be sent in the REP field of a SOCKS5 message. Implementations MUST NOT send any of the extended codes unless the initiator has indicated that it understands the "Tor Extended SOCKS5 Authentication" as part of the version identifier/method selection SOCKS5 message.
Where:
* X'E0' Hidden Service Not Found
The requested Tor Hidden Service was not reachable.
* X'E1' Hidden Service Not Reachable
The requested Tor Hidden Service was not found.
To me it is clear that the two are messed up, but I'm not sure what's the correct order. X'E0' means either it couldn't be found or it is not reachable, but is the description wrong or the error message? Regards, Sebastian (bastik)
Sorry this response took so long. I've been kind of busy. On Sat, 01 Mar 2014 13:57:34 +0100 "Sebastian G. <bastik.tor>" <bastik.tor@googlemail.com> wrote:
To me it is clear that the two are messed up, but I'm not sure what's the correct order.
Indeed. Since there isn't a clear advantage to going one way or another for this, 0xE0 should be not found, 0xE1 should be not available. Looking at some of the stuff nickm added: * What should a client if it gets a value here it does not recognize? (wrt status code in the response from the server) All response codes that are not 0x00 are defined as a failure state, and the server is required to drop the connection after sending one. I'm not sure client behavior needs to be specified here. * What do these do? What is their behavior? Are they client-only? (wrt The USERNAME/PASSWD keys that are reserved) My intention was to reserve keys required to add support for doing RFC1929 style authentication if we desire in the future that is separate from whatever other keys we decide to use in the future. (As a "Yes, these actually for a username/password, don't abuse them for other things"). Client-only, unless reserving this isn't useful (It might not be, there was some grumbling about one day supporting authentication again). "PASSWD" should be "PASSWORD" instead here I guess (or "USERNAME" should be "UNAME" to be consistent with RFC1929). * What should a client if it gets a value here it does not recognize? (wrt Key/Value pairs from the server contained in the response) There's three options here, "ignore", "drop the connection" or, "client sends Version/Status after receiving the response". I believe that the 3rd option is the best. "Ignore" may cause problems if we send important things back in the response (nickm asked for this to be added so I did, but I'm not clear on what it will be used for). "Drop" is not forward compatible. * Should we recommend any namespace conventions for these? Yes, probably. I have no strong preference for what sort of convention is used. "tor.streamIsolation", "scramblesuit.password" etc? * Actually, should this perhaps be controlled by additional KEY? (re: Response codes). I don't think this is necessary. Explicitly specifying that after sending/receiving a status code that is not 0x00 (Defined as Success in RFC1928, the server/client MUST drop the connection should be sufficient? (I'm not sure either) Regards, -- Yawning Angel
On 07 Mar (14:03:35), Yawning Angel wrote:
Sorry this response took so long. I've been kind of busy.
On Sat, 01 Mar 2014 13:57:34 +0100 "Sebastian G. <bastik.tor>" <bastik.tor@googlemail.com> wrote:
To me it is clear that the two are messed up, but I'm not sure what's the correct order.
Indeed. Since there isn't a clear advantage to going one way or another for this, 0xE0 should be not found, 0xE1 should be not available.
Looking at some of the stuff nickm added:
* What should a client if it gets a value here it does not recognize? (wrt status code in the response from the server)
All response codes that are not 0x00 are defined as a failure state, and the server is required to drop the connection after sending one. I'm not sure client behavior needs to be specified here.
Quoting rfc1928: "When a reply (REP value other than X'00') indicates a failure, the SOCKS server MUST terminate the TCP connection shortly after sending the reply. This must be no more than 10 seconds after detecting the condition that caused a failure." So what about simply terminating the connection which I guess would be a fourth option "Close" ?
* What do these do? What is their behavior? Are they client-only? (wrt The USERNAME/PASSWD keys that are reserved)
My intention was to reserve keys required to add support for doing RFC1929 style authentication if we desire in the future that is separate from whatever other keys we decide to use in the future. (As a "Yes, these actually for a username/password, don't abuse them for other things"). Client-only, unless reserving this isn't useful (It might not be, there was some grumbling about one day supporting authentication again). "PASSWD" should be "PASSWORD" instead here I guess (or "USERNAME" should be "UNAME" to be consistent with RFC1929).
* What should a client if it gets a value here it does not recognize? (wrt Key/Value pairs from the server contained in the response)
There's three options here, "ignore", "drop the connection" or, "client sends Version/Status after receiving the response". I believe that the 3rd option is the best. "Ignore" may cause problems if we send important things back in the response (nickm asked for this to be added so I did, but I'm not clear on what it will be used for). "Drop" is not forward compatible.
Same as above.
* Should we recommend any namespace conventions for these?
Yes, probably. I have no strong preference for what sort of convention is used. "tor.streamIsolation", "scramblesuit.password" etc?
Would this be *appended* to a client given key like for instance "myapp1:tor.streamIsolation" or it would be a hardcoded string key that the client needs to use in order to enable the "feature". I can see one use for having custom keys along with a name space which is to having a way to identify the SOCKS connection on the control port for knowing in which country the exit is for instance (or whatever info you need). The source port can be use for that but for an external client not knowing it, it might be interesting to be able to ask the control port "What's the exit node of <INSERT_KEY> SOCKS connection". Cheers! David
* Actually, should this perhaps be controlled by additional KEY? (re: Response codes).
I don't think this is necessary. Explicitly specifying that after sending/receiving a status code that is not 0x00 (Defined as Success in RFC1928, the server/client MUST drop the connection should be sufficient? (I'm not sure either)
Regards,
-- Yawning Angel
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, 7 Mar 2014 10:45:14 -0500 David Goulet <dgoulet@ev0ke.net> wrote:
Quoting rfc1928:
"When a reply (REP value other than X'00') indicates a failure, the SOCKS server MUST terminate the TCP connection shortly after sending the reply. This must be no more than 10 seconds after detecting the condition that caused a failure."
So what about simply terminating the connection which I guess would be a fourth option "Close" ?
This is for the auth status, which is different from the RFC1928 REP. But as you point out, the behavior set down for the server is the same as when a non 0x00 REP value is sent. Client behavior is undefined, but since the server will close, it doesn't matter (We could be the better spec and state that clients MUST close).
* What should a client if it gets a value here it does not recognize? (wrt Key/Value pairs from the server contained in the response)
There's three options here, "ignore", "drop the connection" or, "client sends Version/Status after receiving the response". I believe that the 3rd option is the best. "Ignore" may cause problems if we send important things back in the response (nickm asked for this to be added so I did, but I'm not clear on what it will be used for). "Drop" is not forward compatible.
Same as above.
Hmm, ok. I thought it would be nice to allow older clients to interoperate with newer servers that potentially send back more information in the response, but I suppose that isn't required (when we add more key/value pairs that get sent in the response, we can define them to only be sent if the client requests them"). So Close/Drop sounds reasonable here.
* Should we recommend any namespace conventions for these?
Yes, probably. I have no strong preference for what sort of convention is used. "tor.streamIsolation", "scramblesuit.password" etc?
Would this be *appended* to a client given key like for instance "myapp1:tor.streamIsolation" or it would be a hardcoded string key that the client needs to use in order to enable the "feature".
I was thinking the latter "myProtocol.myConfigSetting". So for example, every TBB connection would send "tor.sessionIsolation"/"Some Session ID", every ScrambleSuit pt client would send "scramblesuit.password"/"Base32 encoded k_B" etc. This model makes arg handling with nested socks client/server pairs fairly easy as well (Think Tor->ScrambleSuit->Meek as a example), since each step can strip off the args it handled and forward the rest to the next SOCKS proxy in the chain. Not sure if the inability to nest multiple invocations of the same protocol is a problem (Tor->ScrambleSuit->obfs3->ScrambleSuit would not work because 2 "scramblesuit.password" keys need to be sent). Back to the forward compatibility thing, we could also define "tor.optional", for things that can safely be ignored if not understood. Not sure if such things exist (most of the things I can think of for key/value pairs are mandatory).
I can see one use for having custom keys along with a name space which is to having a way to identify the SOCKS connection on the control port for knowing in which country the exit is for instance (or whatever info you need). The source port can be use for that but for an external client not knowing it, it might be interesting to be able to ask the control port "What's the exit node of <INSERT_KEY> SOCKS connection".
Is a custom key needed for this? The query you used as an example could just as easily be done without any SOCKS extensions as "What's the exit node of <Insert Source Address/Port> SOCKS connection" couldn't it? One final open question, are there any other status codes that people think should be defined beyond the HS ones and the PT ones? Regards, -- Yawning Angel
On 08 Mar (06:12:41), Yawning Angel wrote:
On Fri, 7 Mar 2014 10:45:14 -0500 David Goulet <dgoulet@ev0ke.net> wrote:
Quoting rfc1928:
"When a reply (REP value other than X'00') indicates a failure, the SOCKS server MUST terminate the TCP connection shortly after sending the reply. This must be no more than 10 seconds after detecting the condition that caused a failure."
So what about simply terminating the connection which I guess would be a fourth option "Close" ?
This is for the auth status, which is different from the RFC1928 REP. But as you point out, the behavior set down for the server is the same as when a non 0x00 REP value is sent. Client behavior is undefined, but since the server will close, it doesn't matter (We could be the better spec and state that clients MUST close).
* What should a client if it gets a value here it does not recognize? (wrt Key/Value pairs from the server contained in the response)
There's three options here, "ignore", "drop the connection" or, "client sends Version/Status after receiving the response". I believe that the 3rd option is the best. "Ignore" may cause problems if we send important things back in the response (nickm asked for this to be added so I did, but I'm not clear on what it will be used for). "Drop" is not forward compatible.
Same as above.
Hmm, ok. I thought it would be nice to allow older clients to interoperate with newer servers that potentially send back more information in the response, but I suppose that isn't required (when we add more key/value pairs that get sent in the response, we can define them to only be sent if the client requests them").
So Close/Drop sounds reasonable here.
* Should we recommend any namespace conventions for these?
Yes, probably. I have no strong preference for what sort of convention is used. "tor.streamIsolation", "scramblesuit.password" etc?
Would this be *appended* to a client given key like for instance "myapp1:tor.streamIsolation" or it would be a hardcoded string key that the client needs to use in order to enable the "feature".
I was thinking the latter "myProtocol.myConfigSetting". So for example, every TBB connection would send "tor.sessionIsolation"/"Some Session ID", every ScrambleSuit pt client would send "scramblesuit.password"/"Base32 encoded k_B" etc.
This model makes arg handling with nested socks client/server pairs fairly easy as well (Think Tor->ScrambleSuit->Meek as a example), since each step can strip off the args it handled and forward the rest to the next SOCKS proxy in the chain. Not sure if the inability to nest multiple invocations of the same protocol is a problem (Tor->ScrambleSuit->obfs3->ScrambleSuit would not work because 2 "scramblesuit.password" keys need to be sent).
Back to the forward compatibility thing, we could also define "tor.optional", for things that can safely be ignored if not understood. Not sure if such things exist (most of the things I can think of for key/value pairs are mandatory).
I can see one use for having custom keys along with a name space which is to having a way to identify the SOCKS connection on the control port for knowing in which country the exit is for instance (or whatever info you need). The source port can be use for that but for an external client not knowing it, it might be interesting to be able to ask the control port "What's the exit node of <INSERT_KEY> SOCKS connection".
Is a custom key needed for this? The query you used as an example could just as easily be done without any SOCKS extensions as "What's the exit node of <Insert Source Address/Port> SOCKS connection" couldn't it?
That would work (and works) if you know the source port and for that you basically need to be the client who made that request unless you happily parse netstat :P. So here is an exemple, I have 5 differents apps using the SOCKSPort, I might be interested in asking tor daemon what's the exit point of my app number 3? That could be interesting to ask the control port something like "Give me exit relay country for SOCKS port myapp3.insert.namespace.here". Not sure that it's or could be possible but maybe just something to think about. Cheers! David
One final open question, are there any other status codes that people think should be defined beyond the HS ones and the PT ones?
Regards,
-- Yawning Angel
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sat, 8 Mar 2014 09:08:06 -0500 David Goulet <dgoulet@ev0ke.net> wrote: [snippity]
I can see one use for having custom keys along with a name space which is to having a way to identify the SOCKS connection on the control port for knowing in which country the exit is for instance (or whatever info you need). The source port can be use for that but for an external client not knowing it, it might be interesting to be able to ask the control port "What's the exit node of <INSERT_KEY> SOCKS connection".
Is a custom key needed for this? The query you used as an example could just as easily be done without any SOCKS extensions as "What's the exit node of <Insert Source Address/Port> SOCKS connection" couldn't it?
That would work (and works) if you know the source port and for that you basically need to be the client who made that request unless you happily parse netstat :P. So here is an exemple, I have 5 differents apps using the SOCKSPort, I might be interested in asking tor daemon what's the exit point of my app number 3? That could be interesting to ask the control port something like "Give me exit relay country for SOCKS port myapp3.insert.namespace.here".
Not sure that it's or could be possible but maybe just something to think about.
Ah I see. I'd feel better about the namespace and "how easy would this be to implement" if this sort of thing was done via a separate key/value pair. So in addition to the keys I specified we could reserve "appID" as a key for this (Eg: "appid"/"tbb<SessionID>", "timb<SessionID>", etc). With prefixing the keys, the arg processing code for everything needs to be appid aware (optional thing should be optional, and easy to ignore). Regards, -- Yawning Angel
participants (5)
-
David Goulet -
Fabio Pietrosanti (naif) -
George Kadianakis -
Sebastian G. <bastik.tor> -
Yawning Angel