[tor-dev] How to integrate an external name resolver into Tor
jeremyrand at airmail.cc
Thu Aug 4 22:37:18 UTC 2016
> On Tue, Aug 2, 2016 at 5:10 PM, Jeremy Rand <jeremyrand at airmail.cc> 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
>>> 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.
>> 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
> 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?
I'm looking at the docs for StreamEvent in Stem:
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the tor-dev