Nick Mathewson: > On Tue, Aug 2, 2016 at 5:10 PM, Jeremy Rand <jeremyrand@xxxxxxxxxx> wrote: >> Nick Mathewson: >>> Hi, all! >>> >>> I've seen a couple of emails from people looking into new ways to do >>> naming for onion services. That's great! Before anybody gets too >>> far, I'd like to send this quick note to let you know that integrating >>> stuff like this into Tor is actually easier than you think. >>> >>> Here's how you do it, using a Tor controller. (See control-spec.txt >>> for protocol documentation. Also see one of the several friendly >>> libraries, like steam, that exist to interface with Tor over this >>> protocol.) >>> >>> First, you set the Tor option "__LeaveStreamsUnattached". This tells >>> Tor that it shouldn't try to handle new client requests immediately, >>> but it should instead let the controller take responsibility. >>> >>> In the controller, you make sure that you are watching STREAM events >>> so that you find out about new streams. >>> >>> Whenever there's a new stream, you check its address. If the address >>> is one that you don't want to rewrite, you just call ATTACHSTREAM on >>> it, with a circuit ID of 0. (The 0 means "Tor, you figure out how to >>> attach this one.". >>> >>> Otherwise, you do whatever magic dance you do in order to find out the >>> real address for the stream. >>> >>> If the lookup operation is successful, you say "REDIRECTSTREAM (stream >>> ID) (new address". And then you ATTACHSTREAM as above. >>> >>> If the lookup operation fails, you call "CLOSESTREAM (stream ID) 2". >>> (The 2 means "resolve failed". >>> >>> And that's it for the Tor integration! All you need to do now is >>> figure out how the name lookup works. >>> >>> cheers, >>> >> >> Hi Nick, >> >> Let's say that the name lookup operation will generate network traffic, >> and therefore should be subject to stream isolation. (This is the case >> for a subset of Namecoin-based lookup methods.) >> >> How can a Tor controller obtain the needed information to perform stream >> isolation on the lookup, prior to issuing ATTACHSTREAM? > > Conceptually, a controller doesn't isolate streams: the streams are > isolated based on their own properties, so that's more of a client > thiing. > > One of the properties that you can use for isolation here is the SOCKS > username and password: two streams with different SOCKS credentials > should never be sent over the same circuit. This should make stream > isolation happen just fine. > > [This is assuming that you use 'ATTACHSTREAM' with a circuit ID of 0, > and let Tor make its own isolation decisions.] > > Is that about what you wanted to know? > > cheers, > Hi Nick, I'm looking at the docs for StreamEvent in Stem: https://stem.torproject.org/api/response.html#stem.response.events.StreamEvent And I don't see any obvious way to get the SOCKS auth data from that. Using the SOCKS auth data was, indeed, the first thought that occurred to me. Is there a way to get the SOCKS auth data from a StreamEvent prior to issuing ATTACHSTREAM, so that I can use that data when performing the name lookup? Cheers, -Jeremy
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev