August 2012 - tor-dev - lists.torproject.org

Proposal 205: Remove global client-side DNS caching
by Nick Mathewson 19 Dec '12

19 Dec '12

Filename: 205-local-dnscache.txt Title: Remove global client-side DNS caching Author: Nick Mathewson Created: 20 July 2012 Status: Open 0. Overview This proposal suggests that, for reasons of security, we move client-side DNS caching from a global cache to a set of per-circuit caches. This will break some things that used to work. I'll explain how to fix them. 1. Background and Motivation Since the earliest Tor releases, we've kept a client-side DNS cache. This lets us implement exit policies and exit enclaves -- if we remember that www.mit.edu is 18.9.22.169 the first time we see it, then we can avoid making future requests for www.mit.edu via any node that blocks net 18. Also, if there happened to be a Tor node at 18.9.22.169, we could use that node as an exit enclave. But there are security issues with DNS caches. A malicious exit node or DNS server can lie. And unlike other traffic, where the effect of a lie is confined to the request in question, a malicious exit node can affect the behavior of future circuits when it gives a false DNS reply. This false reply could be used to keep a client connecting to an MITM'd target, or to make a client use a chosen node as an exit enclave for that node, or so on. With IPv6, tracking attacks will become even more possible: A hostile exit node can give every client a different IPv6 address for every hostname they want to resolve, such that every one of those addresses is under the attacker's control. And even if the exit node is honest, having a cached DNS result can cause Tor clients to build their future circuits distinguishably: the exit on any subsequent circuit can tell whether the client knew the IP for the address yet or not. Further, if the site's DNS provides different answers to clients from different parts of the world, then the client's cached choice of IP will reveal where it first learned about the website. So client-side DNS caching needs to go away. 2. Design 2.1. The basic idea I propose that clients should cache DNS results in per-circuit DNS caches, not in the global address map. 2.2. What about exit policies? Microdescriptor-based clients have already dropped the ability to track which nodes declare which exit policies, without much ill effect. As we go forward, I think that remembering the IP address of each request so that we can match it to exit policies will be even less effective, especially if proposals to allow AS-based exit policies can succeed. 2.3. What about exit enclaves? Exit enclaves are already borken. They need to move towards a cross-certification solution where a node advertises that it can exit to a hostname or domain X.Y.Z, and a signed record at X.Y.Z advertises that the node is an enclave exit for X.Y.Z. That's out-of-scope for this proposal, except to note that nothing proposed here keeps that design from working. 2.4. What about address mapping? Our current address map algorithm is, more or less: N = 0 while N < MAX_MAPPING && exists map[address]: address = map[address] N = N + 1 if N == MAX_MAPPING: Give up, it's a loop. Where 'map' is the union of all mapping entries derived from the controller, the configuration file, trackhostexits maps, virtual-address maps, DNS replies, and so on. With this design, the DNS cache will not be part of the address map. That means that entries in the address map which relied on happening after the DNS cache entries can no longer work so well. These would include: A) Mappings from an IP address to a particular exit, either manually declared or inserted by TrackHostExits. B) Mappings from IP addresses to other IP addresses. C) Mappings from IP addresses to hostnames. We can try to solve these by introducing an extra step of address mapping after the DNS cache is applied. In other words, we should apply the address map, then see if we can attach to a circuit. If we can, we try to apply that circuit's dns cache, then apply the address map again. 2.5. What about the performance impact? That all depends on application behavior. If the application continues to make all of its requests with the hostname, there shouldn't be much trouble. Exit-side DNS caches and exit-side DNS will avoid any additional round trips across the Tor network; compared to that, the time to do a DNS resolution at the exit node *should* be small. That said, this will hurt performance a little in the case where the exit node and its resolver don't have the answer cached, and it takes a long time to resolve the hostname. If the application is doing "resolve, then connect to an IP", see 2.6 below. 2.6. What about DNSPort? If the application is doing its own DNS caching, they won't get much security benefit from here. If the application is doing a resolve before each connect, there will be a performance hit when the resolver is using a circuit that hadn't previously resolved the address. Also, DNSPort users: AutomapHostsOnResolve is your friend. 3. Alternate designs and future directions 3.1. Why keep client-side DNS caching at all? A fine question! I am not sure it actually buys us anything any longer, since exits also have DNS caching. Shall we discuss that? It would sure simplify matters. 3.2. The impact of DNSSec Once we get DNSSec support, clients will be able to verify whether an exit's answers are correctly signed or not. When that happens, we could get most of the benefits of global DNS caching back, without most of the security issues, if we restrict it to DNSSec-signed answers.

6 12

Help with pf and iOS
by sid77＠slackware.it 28 Sep '12

28 Sep '12

Hi all, it took me a year or so but I've finally managed to build Tor for iOS with a working support for TransPort, as you can see on: https://github.com/sid77/evelyn/blob/master/tor/make.sh The next natural step is to hack together full device torification as iOS jailbroken devices can run pf (without ALTQ support). I'm not very comfortable with pf and pfctl so my first step was to head out to https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#BSDPF looking for some clue. However, jailbroken iOS' ifconfig can not bring up a second loopback interface (I think the kernel is not allowing it) so I had to test out some custom rules, my current pf.conf is as follow: -8<- scrub in rdr pass on lo0 inet proto tcp all -> 127.0.0.1 port 9040 rdr pass on lo0 inet proto udp to port domain -> 127.0.0.1 port domain block return out pass quick on lo0 keep state pass out quick inet proto tcp user nobody flags S/SA modulate state pass out quick route-to lo0 inet proto udp to port domain keep state pass out quick route-to lo0 inet proto tcp all flags S/SA modulate state -8<- taken from: https://github.com/sid77/mobiletor/blob/master/pf.conf I apply it running this script: https://github.com/sid77/sbsettingstor/blob/master/com.sbsettingstor.enable Tor is running as user nobody (not really secure but I still have to figure out system user management on the platform) and answering DNS queries on 127.0.0.1:53. This solution is failing *REALLY* hard as I managed to run into a kernel panic as soon as I tried to generate some traffic with Mobile Safari or Cydia. Is there any pf guru out there which can give me some insights? Ciao, Marco

4 4

DNS(SEC) draft update
by Ondrej Mikle 16 Sep '12

16 Sep '12

Hi Nick, I've revised the DNS draft, attaching it. In section 4 there are some options for integration with libunbound, but each of them requires some work with the stock libunbound code. Ondrej

3 3

Parallel release series for directory authorities?
by Nick Mathewson 06 Sep '12

06 Sep '12

Hi, all! Here's an idea I had for directory authorities and the 0.2.3 release series. "As you know Bob," Tor 0.2.3 will be stable very soon, and I'm hoping not to take any more patches for it except for important security issues. I want 0.2.4 to come out very early next year. But in the meantime, to support 0.2.4, and to deploy security/reliability features to the network early, there are some directory consensus features that we'd want to deploy before the rest of 0.2.4 is done and stable. In particular, I'd like directories to be able to reach consensus on IPv6 addresses (6363), and I'd like to try out the code that Mike wrote to make the bandwidth voting system more robust against dishonest during its startup phase (2286). So here's my plan: Make a "maint-0.2.3-da" branch based on 0.2.3, plus feature patches for directory authorities. It gets patches from the stable series (0.2.3), plus directory-authority features under development. It would get merged-forward into 0.2.4, to make sure that 0.2.3-da and 0.2.4 behavior stay in sync. This way we can get new authority features working in time to support 0.2.4 clients, but without forcing too many authorities to run 0.2.4 before it's ready, and without forcing us to make feature changes in 0.2.3 proper. Thoughts? yrs, -- Nick

7 8

Tor on IPv6 roadmap and status page
by Linus Nordberg 02 Sep '12

02 Sep '12

Hi, The roadmaps/Tor/IPv6 [1] wiki page has been started with the goal of communicating the status of the work with Tor on IPv6. Additionally, searching for Trac tickets with the keyword "ipv6" [2] might give a picture of what's going on. Asking here or highlighting ln5 on #tor-dev is of course another perfectly fine option. [1] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6 [2] https://trac.torproject.org/projects/tor/query?keywords=~ipv6 -- Linus

4 5

[GSoC] [Stegotorus] Recent activities
by vmon 31 Aug '12

31 Aug '12

Hey Zack, I know you are super busy packing for your big move, but I thought as tomorrow is the hard deadline for GSoC, is not a bad ideas to give you some final update. So most of last week I spent on the conflict that occurred between libcurl and libevent having their eyes on the same socket. I tried different ugly and uglier solutions but finally settled on this one which is not that bad: http://stackoverflow.com/questions/12021217/how-to-ask-libcurl-not-to-liste… After that, I'm passing all time line tests now. However, when I look at the client log, I see that some of the sequence no are missing in the recv: like this 203.7169 [debug] recv: <3.81> receiving block 42 <d=0 p=9 f=DAT> T:203.7170: ckt 3 <ntp 1 outq 0>: recv 42 <d=0 p=9 f=DAT> and the next recv is like this: 203.7926 [debug] recv: <3.99> receiving block 60 <d=0 p=1 f=DAT> T:203.7927: ckt 3 <ntp 1 outq 0>: recv 60 <d=0 p=1 f=DAT> Is this for sure an error and loss of data? or there is a normal situation that such a thing can happen? For example when the whole block can't be sent over one connection? (otherwise how do the tl tests all pass?). Further more, I merged the payload scraper and stegotorus. I this way, http_apache checks for the payload database and if it's not there it calls the scraper (it needs apache to be installed on the same machine). These all are commited on the github. I started writing a unit test that fetch a webpage directly (using curl) and through stegotorus and check if they are the same. I thought curl is best approximation of a browser that is available to us. But as I don't think I can finish that till tomorrow, I'm going to spend the remaining time on documenting the 'uri transport protocol' and deal with small issues. After we are done with the evaluation, I'll go back to unit testing. Thanks for your help. Cheers, vmon

2 2

Re: [tor-dev] TBB Gentoo ebuild
by julian 27 Aug '12

27 Aug '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 12 Aug 22:56 Mansour Moufid: > Even with webrsync you still have to trust the mirror(s), and then > the Gentoo release infrastructure... Forgive me my bluntness, but how is that different from trusting you? The methods are reliable, being Manifests and webrsync, the unknown variable is the trust you give the ones providing you with ebuilds. But those are identified by gpg on both levels. And the TBB is even worse, cause I also have to trust what's in the binaries. There is no way to tell what was actually compiled there. It could be something different than the sources on the git server. 13 Aug 00:28 Matthew Finkel: > 4) Given 3), is there a reason Tor is not at least an optional > RDEPEND for torbrowser via a USE flag (or another way)? There are no optional runtime-only dependencies in gentoo, this could change with GLEP 62. http://www.gentoo.org/proj/en/glep/glep-0062.html I could however tell the user after compilation that he might want to use tor with this...erm... but I thought that's obvious. The fact that it's not forced for RDEPEND is simply, because there are setups where this is not wanted/required. 13 Aug 00:28 Matthew Finkel: > 5) If you did/do intend to create an ebuild for the TBB and not > just the browser, it should provide the exact same experience as if > the user downloaded it from torproject.org. I think this should > include Vidalia launching Torbrowser once the network is > configured. Definitely not. The intention is not to provide an all-in-one experience. I already had those arguments with the guys from #tor All I am interested in is the question about the firefox build-time configuration and if different build-time configurations could lead to vulnerability in the tor network. If there is the slightest doubt about that, I will remove this ebuild at once or fix it. - - hasufell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQOpaJAAoJEFpvPKfnPDWzpI4H/igZDuVGyjdKEl9SvvV9gnY0 72esQTiHfx00gO42lOguutwBX54DV/S7HggEZy1P9UIi5gfJckrFKsM3Y9oD9tUX X9EZA6WEU3F90MD0gFFxH2jcoEbm85UfjJkEwI2Hy1+lEOPAZqzBV1F0sBE/Xd/U WwIgAHy8jKsTI1RTIW8r4VOoexifCllWvjbKiDNxeeixTQhwhvrCWnbqTI0WKR95 Er6LNwwYNh+Ugu7s6OwR7o3cUAuOXt3LUjf45bEGAgPF+lrqsXrfB9N5ANu+3177 94sxHgzYkRSsORjjl678/tZFfyp1jagX1FcT6O1dd/J4sHqfRdyZfy29d0DH/e0= =gCI5 -----END PGP SIGNATURE-----

3 3

First five Tor tech reports
by Karsten Loesing 27 Aug '12

27 Aug '12

Hi Roger, hi Nick, here are the first five metrics tech reports that I'd like to turn into Tor tech reports (see #5405 for the idea behind this). If you agree that this is a good idea, I'll push the sources to tech-reports.git and put the PDFs on the Tor website. I need your confirmation for each report as part of the process, though. - https://people.torproject.org/~karsten/volatile/bridge-stability-2011-10-31… - https://people.torproject.org/~karsten/volatile/blocking-2011-09-15.pdf - https://people.torproject.org/~karsten/volatile/detector-2011-09-09.pdf - https://people.torproject.org/~karsten/volatile/relay-stability-2011-06-30.… - https://people.torproject.org/~karsten/volatile/data-2011-03-14.pdf Thanks, Karsten

6 15

https://gitweb.torproject.org/check.git
by bgt56zhn＠Safe-mail.net 26 Aug '12

26 Aug '12

Where is the code powering check.torproject.org? There is https://gitweb.torproject.org/check.git, but the repo has no commits. Thanks

3 2

an alternate MyFamily definition
by tagnaq 24 Aug '12

24 Aug '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, when requesting a new group by feature for compass [1] (#6662 [2]) I discussed with Karsten about how to handle asynchronous/overlapping families: karsten: > Here's an example. Assume we have three relays: A, B, and C. These > relays state the following family relationships: > > A: A, B B: A, B, C C: B, C > > We require mutual agreement about being in the same family, so we > could either come up with family A, B or with family B, C. Which > one is correct? I proposed to go with family = A, B, C because there is a mutual agreement between A<->B and B<->C. A and C agreed to be in a family with B, and B agreed to be in a family with A and C. Such configurations can be found in the wild mostly due to incomplete MyFamily configurations on relays in big families. As every big relay operator knows configuring families is a non-trivial effort with a growing number of relays. Now I thought about it and wanted to suggest this MyFamily interpretation as an alternate approach to the fully mutual setup where *every* relay must be reconfigured as opposed to just two of them. Why? This would reduce the configuration effort required when adding a new relay to *two* relays regardless of how many relays are in your family. Now, the MyFamily configuration overhead for big families is a well known problem so I suppose someone else did already propose this approach? What do you think about it? [1] https://compass.torproject.org [2] https://trac.torproject.org/projects/tor/ticket/6662 a additional example to make this clearer: A: A, B, C B: A, B, C C: A, B, C D: A, B, C, D family = A, B, C A family member must have a *mutual* agreement with at least *one* node. -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAlA2YkoACgkQyM26BSNOM7Yp2wD/VTBw8BmUJlRZtIfXahIGX+t0 zwzP6MfRDwgPCsQMeEUA/3dUyyoq91Fx4lmihWHis2DZNAoM/CHh2MnwgMNL/W1W =FWRU -----END PGP SIGNATURE-----

3 4