Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
On 08 Mar (06:12:41), Yawning Angel wrote: On Fri, 7 Mar 2014 10:45:14 -0500 David Goulet dgou...@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 signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
On Sat, 8 Mar 2014 09:08:06 -0500 David Goulet dgou...@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/tbbSessionID, timbSessionID, 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 signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
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@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 signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
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@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 signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
On Fri, 7 Mar 2014 10:45:14 -0500 David Goulet dgou...@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 signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
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) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
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'', 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.
