[tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)

Sat Mar 8 14:08:06 UTC 2014

On 08 Mar (06:12:41), Yawning Angel wrote:
> On Fri, 7 Mar 2014 10:45:14 -0500
> David Goulet <dgoulet at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140308/b5f70fa8/attachment.sig>