test unix-domain sockets

[Brian Warner]

A quick glance at twisted/internet/unix.py suggests that the unix-domain Server and Port classes inherit from their tcp.* cousins, which would mean .startTLS() should work on them. That'd be great, because then we could use unix-domain sockets for e.g. SOCKS and txtorcon connections, instead of localhost-bound TCP.

We should test this. The test should do tub.listenOn("unix:/tmp/filename"). We also need a connection handler that knows how to make unix-domain outbound sockets, maybe something to wire a TCP socket to a unix one.

[meejah]

FWIW, in the release-1.x branch of txtorcon, I do have SOCKS5-over-unix-sockets-over-Tor working, at least from a client-side perspective.

This should allow operating both client-side and service-side without opening any TCP connections besides Tor's outbound-only connections. Also, it's not really necessary to use TLS in such a situation: the service-bound traffic is encrypted and authenticated.

[Brian Warner]

Yeah, we've pondered this one before (w.r.t. I2P, I think), but Foolscap's whole security/identity model is based around the hash of the TLS cert. It'd be a pretty deep change to delegate responsibility for this to an external transport provider. And in some cases it wouldn't even be correct: suppose you've got a unix socket to the local Tor daemon which makes a Tor connection through an exit node to a plain TCP server.. the TubID should be that of the target server, independent of any encryption provided between the local daemon and the exit node.

It feels a bit weird that things are being double-encrypted, but it's probably easier and more consistent to treat the connection as unprotected (even if it's not), and always put Foolscap's TLS/TubID layer on top.