The State of the DNS and Tor Union (also: a DNS UDP - >TCP shim)

[coderman]

great info!  my comments below...

On Fri, Jul 2, 2010 at 6:15 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> ...
> While Tor users should always use Torbutton[-1] for their web browsing,
> not all applications have an equivalent plugin available. Torbutton
> addresses DNS leaks from within Firefox by ensuring that Firefox uses
> the local Tor proxy for its DNS name lookup requests. However, other
> applications may not do this and may, as a result, leak DNS requests.
> We try to discover if popular applications are leaky but, ultimately,
> any application that makes a DNS request may compromise your anonymity
> unless specifically configured to make that request over Tor.  The
> central concern is thus for an applications that don't know to send
> their name lookup requests via Tor, or don't know how to do so.  Tor
> can't protect these applications' requests.

a better wording:

"... ultimately, any application that uses DNS or UDP may compromise
your anonymity."

best intentions fail in the face of an attacker in most circumstances.
Java can be configured to use explicit resolver endpoints regardless
of suggested default proxy or other configuration.  raw UDP sockets
via third party plug-ins are worst case.

note that even with transparent proxy configuration and DNS port you
are at risk if the attacker can direct explicit DNS requests to a
local resolver (over link-local route, not default gateway). this type
of attack affects all VPN or transparent proxy configurations that do
not use a /29 point-to-point router path.

to add insult to injury, many commercial Linux based routers like
ActionTek and D-Link use dproxy-nexgen resolvers accessible at
link-local 192.168.1.1. a reverse lookup of the gateway itself
provides not just the internal address but also the public IP and
hostname from ISP. there are other caching resolvers used in captive
wifi portals and other locations with same behavior.



...
> Having a local DNS server is useful; many applications may only support
> SOCKS4, rather than SOCKS4A or SOCKS5 - their failure could lead to
> de-anonymization. It is also useful to ensure that possible DNS leaks
> will fail closed - if your system only knows about 127.0.0.1:53, it's
> hard but not impossible to leak DNS packets to the public internet.

not really hard in any sense of the word.  :(




> ======================= Old Hope: tor-proxy-dns ========================
> ...
> Once, a long time ago, we had a super star programmer named Tup in our
> community. He was anonymous to us. He was a programming machine and
> we really miss him. We often wonder and worry about what has happened
> to our friend. He would crank out code in a myriad of languages that
> served all sorts of useful purposes. One of the things that he wrote
> was a small program in Python called tor-proxy-dns; this software was
> useful but written in Python, abandoned by the missing superstar, and
> generally lost to the sands of time.

PERL, but that doesn't detract from the awesome that is Tup.

sadly, we are not currently temporally propinquitous with Tup.



> VirtualAddrNetwork is an obscure but very useful option for decreasing
> latency at connection time. When enabled, Tor will automatically return
> a specially mapped IP address. Eventually, Tor will learn the real
> address and keep an internal mapping between the virtual address and the
> real address. Tor remembers this mapping for the duration of execution
> but it is not saved between Tor restarts. This works except in cases
> where the IP address is noted by an application, such as OpenSSH. This
> will decrease perceived and actual latency but it has frustrating side
> effects for some applications.

the other trade-off with this approach is that is behaves very poorly
with some applications that expect name resolution to fail on
un-reachability (like .onion or .exit) rather than in-determinate
connection establishment.

that is, your application may resolve a random site or hidden service
immediately and attempt to connect, but this attempt (via transparent
transport access) may hang indefinitely for minutes before success or
failure.  some prefer to have more explicit control over these
resolution timers and timeouts.



> ===================== A New Hope: ttdnsd ===============================
>...

coming soon: <clever play on star wars idiom>

the best of all worlds would combine:
- virtualaddrnetwork based immediate resolve and map
- dnsport transparent resolve through Tor
- ttdnsd based tunneled TCP DNS from exit
- host based interception and/or filtering mechanisms against side
channels around the above

until then you're exposing yourself to specific attacks and providing
poor end user experience in other situations.



> ========================= Caching Answers ==============================
> ...

a discussion of negative caching might be useful. some people
encounter situations where they get a positive responsive from an
explicit request but host based resolver facilities still return not
found. see also host based caches like nscd.



> ==================== Additional Privacy Issues =========================
>
> Some applications may provide a proxy setting but disregard it in
> certain circumstances. ttdnsd can make the use of these applications
> safer with regard to DNS leaks.

not really. this is the exception rather than the rule, or even common case.  :(


best regards,
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/