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

[Jeremy Rand]

Nick Mathewson:
> 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,
> 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160804/d32ec944/attachment.sig>