[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