[tor-dev] How to integrate an external name resolver into Tor

Nick Mathewson nickm at alum.mit.edu
Thu Aug 4 13:09:05 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
>> 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,
-- 
Nick


More information about the tor-dev mailing list