adns and TOR

[Jacob Appelbaum]

On 10/21/15, Ian Jackson <ijackson at chiark.greenend.org.uk> wrote:
> Werner Koch writes ("Re: adns and TOR"):
>> On Tue, 20 Oct 2015 17:11, ijackson at chiark.greenend.org.uk said:
>> > I am not opposed to supporting SOCKS.  But I don't understand why so
>> > much of this has to be done in adns.  Can't SOCKS provide `connect' ?
>> > Is there not some library with the SOCKS protocol client ?
>>
>> I think there are libraries but
>>
>>   - they are overkill because we do not need to implement any
>>     SOCKS authenticatian method,
>>   - probably won't fit into ADNS event driven model,
>>   - adds an other dependency.
>
> These are fairly convincing reasons.  I don't fancy trying to break
> out asynchronous SOCKS support into its own library at this stage,
> which is what the alternative would probably look like.

Authentication is actually important for Tor but not for obvious
reasons. We use it to signal that we'd like a new Tor circuit. A
freshly generated (random) username and password would signal to Tor
to not attach the SOCKS TCP stream to any current circuit. This is an
important thing to consider - do you want to download your keyring
updates all on a single circuit? Perhaps? Perhaps not?

>
>> > Also, I don't understand why it isn't better to use adns_init_strcfg.
>> > Do we want other random utilities, eg command line utilities, to be
>> > able to use the socksified adns ?
>>
>> You mean a new option?  Makes sense to me.  AFAICS, those options set an
>> adns_if flag anyway.  My current GnuPG configure checks whether that
>> flag is in adns.h to decide whether Tor support will be possible.  A
>> function to ask for that at runtime would of course be safer.
>
> I mean a textual config option in the config file (the resolv.conf,
> which adns lets you provide a different one of).  To use the TOR
> resolver you're going to have to specify nameservers anyway, so you
> already have a custom resolv.conf, presumably.
>
> The init flags are for properties of the application's interaction
> with the adns API, not really for how to configure where DNS data
> comes from.  The latter is defined in the config file.
>
>> > And I don't understand why it is a good idea to teach adns about TOR
>> > rather than to have the next-layer-up TOR things know about that.
>> > But perhaps I don't understand how the TOR client software is
>> > structured.  If you point me to something where I could do some
>>
>> Tor is more than a HTTP proxy so you can't use the standard http_proxy
>> thing.  Tor allows to relay all *TCP* traffic.  To accomplish this you
>> send all your traffic via SOCKS.  The problem is that the Tor server and
>> the network has only limited capabilities for DNS.  It would be much
>> cooler if we could ask TOR to retrieve arbitrary RRs but that has not
>> been implemented.  Thus the hack to force the use of TCP for name
>> resolution and to route this over Tor to a public resolver.  Yes, Google
>> can easily manipulate the DNS - it is not safe but that is a different
>> story.
>
> Right.
>

Please read our specs in your free time:

  https://gitweb.torproject.org/torspec.git

> I guess I meant: is it intended that every application program which
> one might want to use to access a TOR service would have to be patched
> to know about TOR, specifically ?

Tor, not TOR. Also - if you want to connect to a .onion (eg: our soon
to be published RFC 7686) - you need to use a proxy that supports it
OR you need an OS that transparently routes TCP traffic into that
proxy. If you're not using SOCKS5 (or SOCKS4a) then you're going to
have trouble resolving .onion names - please see RFC 7686 in the next
few days for more details or read our draft:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

> That seems like it would be a pain.  Surely it would be better to
> allow use of any SOCKSified application.

That is generally how things are done - but SOCKS doesn't really solve
all of the issues as Werner has explained. We don't proxy UDP - we
have a minimal resolver available over a SOCKS4a/SOCKS5 interface.

>
> But I don't know how SOCKS is usually configured.  How do you normally
> tell a SOCKSified client program where to find its SOCKS server ?
>

Generally, you'd tell it the Unix Domain Socket (
/var/lib/tor/sockssocket ) or IP address and port number (eg:
127.0.0.1:9050 ), a username/passsword (which can be anything, see
torspec).

> (For that matter, in the TOR context, how do you tell an application
> to use a different resolver?)

Generally speaking - an application should be made Tor aware -
otherwise you have a problem of something like making local DNS
requests to the local resolver, which leak information about a user's
behavior, then the resolved IP is passed via SOCKS to Tor. If one has
this split in an application, it means a local censor can poison your
DNS and Tor will helpfully connect you to their block page. In the Tor
Browser, we configure everything to work properly by default. With a
package like torsocks, LD_PRELOAD is used to overload unsafe functions
that would leak or violate your privacy, etc.

If you have some specific applications in mind, I can try to explain
how to Torify them or explain why it may not be possible (eg: it uses
UDP and SCTP exclusively).

All the best,
Jacob