adns and TOR

Werner Koch wk at gnupg.org
Tue Oct 20 21:12:05 CEST 2015


On Tue, 20 Oct 2015 17:11, ijackson at chiark.greenend.org.uk said:

> I'm afraid that my enthusiasm for Windows support is still quite low.
> In particular, I definitely don't want to deal with libtool, nor with

Well, well, I keep my own version for Windows.

> I'm afraid this commit is very hard to read in your gitweb due to all
> the whitespace change noise.

Sorry, I forgot to do a separate commit when adding the --use-tor option
to adnshost.  The other chnages are easier to read.  The bulk of changes
is in event.c

> 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.

SOCKS dates back to 1992 and the SOCKS5 version is desrcibed in RFC-1928
from 1996. SOCKS is a pretty simple protocol:

  - connect to the proxy (localhost:9050 for Tor)
  - send hello with requested authenitcation methods (non for us)
  - read response from the proxy (bascially ACK or NACK)
  - send a data block with port and address to the proxy
  - read response from proxy with status code (okay or connection failed)
  - do your work with the server (proxy won't interrupt you anymore)

> 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.

> 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.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




More information about the Gnupg-devel mailing list