[tor-dev] DNSSEC

merc1984 at f-m.fm merc1984 at f-m.fm
Tue Sep 2 01:49:26 UTC 2014

On Mon, Sep 1, 2014, at 11:54, Mike Cardwell wrote:
> The exit nodes do the DNS requests. The client doesn't see an IP address.
> It connects to the Tor SOCKS interface and says, "connect me to hostname
> example.com on port N". It doesn't look up the IP address of
> "example.com"
> and *then* connect to it. Hidden services don't have IP addresses and
> DNS resolution isn't involved in routing connections to them.

So when I request to connect to example.com, that request goes all the
way to the exit node, which then is supposed to do the DNS lookup? 
Again, this is impossible, as .onion domains would be bypassed. 

> I am a fan of DNSSEC and use it on my own domains. However, it wouldn't
> help on Tor as much as you think it would:
> If you're visiting a non-SSL website, the web traffic can still be
> viewed and modified by a malicious exit node regardless of if DNSSEC is
> in use, so DNSSEC doesn't gain us anything here...
> And if you're visiting an SSL secured website, a malicious exit node
> can't view/modify your traffic without triggering certificate alerts
> anyway regardless of the existence of DNSSEC.
> And on top of this, they can route your traffic to whatever IP they
> want. So even if you get a DNSSEC signed response telling you to
> connect to IP address "a.b.c.d", they can still re-route your attempt
> to connect to "a.b.c.d" to whatever IP they want.

That all happens after the DNS lookup has taken place.  That is not the
issue I am raising, but it is concerning that it hasn't been thought of

> DNSSEC and DNSCurve are completely different solutions for completely
> different problems and can be used independently or at the same time.
> I don't think you've effectively said what the problem which you
> want addressing actually is.

First off, I don't trust DNSCurve, given that some algos of elliptic
curve are proven compromised, and I don't care if DNSCurve doesn't use
them.  At this point all of elliptic curve is suspect until proven

Second, it seems clear that no one so far understands the hazard of DNS
Cache Poisoning.  To put this in terms that everyone here believes, if
an exit node does the DNS and is compromised or operating under the
control of a malicious party, that party can subvert DNS requests to
their own malicious websites and dupe login credentials and other key
information from the requester.  Here's more, although I know some here
are too lazy to read it: 

For non-TOR use I have dnscrypt and unbound set up in a rotary, using
resolvers of my choosing, all of which serve my DNS queries encrypted
and signed, and they do not keep logs.  -I- have chosen these resolvers
and they are the most trustworthy that I can arrange at this time.  How
do I know they don't log?  As Schnier says, you have to trust -someone-.
 If you spitball and poo poo every mechanism that comes along, you end
up just letting everything go and turning over all your contacts, your
emails, your searches, even your very voice calls to G**gle.  I will
choose Mom and Pop over G**gle or M$ anytime.

DNSSEC is an attempt to secure DNS from a wide-open vector of attack,
which it seems to me that TOR is all too susceptible to.  It is alarming
to me that DNS cache poisoning hasn't been thought of here.  It's thus
probably being used.  Hell, I'd use it.

http://www.fastmail.fm - Does exactly what it says on the tin

More information about the tor-dev mailing list