great info! my comments below... On Fri, Jul 2, 2010 at 6:15 PM, Jacob Appelbaum <[email protected]> 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 [email protected] with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
