tor-dev September 2012

tor-dev@lists.torproject.org

31 participants
25 discussions

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

Compiling tor against OpenSSL_1_0_2-stable
by Christian Kujau 29 Nov '12

29 Nov '12

Hi, while trying to compile the latest git-checkout against openssl-1.0.2, I've come across the following issues: ---- make[1]: Entering directory `/usr/local/src/tor-git' CC src/common/tortls.o cc1: warnings being treated as errors In file included from /opt/openssl/include/openssl/ssl.h:1382, from src/common/tortls.c:36: /opt/openssl/include/openssl/srtp.h:138: error: redundant redeclaration of ‘SSL_get_selected_srtp_profile’ /opt/openssl/include/openssl/srtp.h:135: note: previous declaration of ‘SSL_get_selected_srtp_profile’ was here make[1]: *** [src/common/tortls.o] Error 1 make[1]: Leaving directory `/usr/local/src/tor-git' make: *** [all] Error 2 ---- There is an open ticket[0] in the openssl bugtracker for this. While the proper solution is to fix openssl/include/openssl/srtp.h, I wanted to compile without -Werror. However, when adding CFLAGS="-Wno-error" during ./configure, -Werror is still added to the ./Makefile and overriding -Wno-error. When adding CFLAGS="-Wno-error" during "make" all the other CFLAGS are gone too. Thus I ended up removing -Werror from the Makefile and tortls.o compiled. While this is really an issue with openssl, I wanted to have this documented, just in case anybody else tries the same. If someone knows of a better workaround (i.e. compiling just tortls.c with -Wno-error and everything else with -Werror), please share! :-) A bit later, compilation stops again: ---- CCLD src/or/tor src/common/libor-crypto.a(aes.o): In function `aes_crypt': aes.c:(.text+0x860): undefined reference to `CRYPTO_ctr128_encrypt' collect2: ld returned 1 exit status make[1]: *** [src/or/tor] Error 1 make[1]: Leaving directory `/usr/local/src/tor-git' make: *** [all] Error 2 ---- Hm, this leaves me puzzled for now. CRYPTO_ctr128_encrypt is still included in openssl-1.0.2 and src/common/aes.o seems to be built with this function included as well, not sure why src/common/libor-crypto.a complains now: ---- $ grep -r CRYPTO_ctr128_encrypt /opt/openssl/ /opt/openssl/include/openssl/modes.h:void CRYPTO_ctr128_encrypt(const unsigned char *in, unsigned char *out, /opt/openssl/include/openssl/modes.h:void CRYPTO_ctr128_encrypt_ctr32(const unsigned char *in, unsigned char *out, Binary file /opt/openssl/bin/openssl matches Binary file /opt/openssl/lib/libcrypto.a matches $ grep -r CRYPTO_ctr128_encrypt . ./src/common/aes.c: CRYPTO_ctr128_encrypt((const unsigned char *)input, Binary file ./src/common/aes.o matches Binary file ./src/common/libor-crypto.a matches ---- Why do I (try to) build against openssl-1.0.2? I'm on Debian/stable which still ships openssl-0.9.8o and I wanted to get rid of this "use a more recent OpenSSL" message during startup :-) Otherwise, today's git-checkout of tor runs just fine when built against openssl-0.9.8 (on powerpc) - yay! Christian. [0] http://rt.openssl.org/Ticket/Display.html?id=2724 -- BOFH excuse #330: quantum decoherence

2 2

automation of open links in new tab in TBB
by jiang song 30 Sep '12

30 Sep '12

Hi, If I use firefox, I can use a simple command line to open a link in a new tab automatically, like firefox www.google.com now I want to open TBB first, and then open a link in a new tab, is there any script or method to automate this operation? I need this automation for some experiment, I know TBB is a modified firefox, so if there are TBB developes here, they may know how to do this, thanks!

2 5

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

automatic play of video with webbrowser
by esolve esolve 26 Sep '12

26 Sep '12

Hi, all: I want to investigate on video streaming on tor. I want to use tor and browser to play some videos for many times so I want to automate the operation. Are there any scripts that can automate the playing of videos(like from youtube,etc) I know playing videos can impediment the anonymity, but that is not my concern. Thanks!

2 1

information about "last_restarted"
by succer110＠tiscali.it 25 Sep '12

25 Sep '12

Hi everyone tor devel! I would like to know more information about last_restarted information. - It's possibile to forge this kind of data or is somehow certified by the tor network? Sometime, while sampling hourly some data by onionoo i've noticed some difference in the uptime by + or - a few seconds in this value. - Any idea of how this is possible?! - In which file do i find the code that handle this value? Thank you! Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/

2 1

Email-based rendezvous for flash proxies
by David Fifield 25 Sep '12

25 Sep '12

I have made a design and written some code for an email-based registration system for flash proxy clients. Registration is the process by which a censored client sends its IP address to request service from an external proxy. In summary, a censored client sends its address in encrypted email over SMTP over TLS to a distinguished email address. A program running on the flash proxy facilitator makes an IMAP connection over TLS, polls for messages, then decrypts them and registers the addresses withing. The email messages are sent by a registration helper program, not the client's own email account, and they appear to come from a dummy address. More information is in the ticket: https://trac.torproject.org/projects/tor/ticket/6383#comment:5 I would appreciate a second look at the design, especially the use of crypto. The ticket's comment number 5 calls out some particular features. This is our first registration system with a claim to being hard to block. This is step 1 that goes through the firewall in the diagram at http://crypto.stanford.edu/flashproxy/#how-it-works. The censor sees a TLS session with a Gmail MX server, followed later by an incoming connection from a flash proxy at a previously unseen IP address. What makes this different than other circumvention ideas is that nothing is sent directly to any published or unpublished Tor relay. David Fifield

1 0

Fwd: New HS protocol
by Robert Ransom 19 Sep '12

19 Sep '12

Note that this scheme is not quite safe to implement with Ed25519 or other DSA-like signature schemes as described; the base point needs to be multiplied by the same number as the public-key group element. ---------- Forwarded message ---------- From: Robert Ransom <rransom.8774(a)gmail.com> Date: Wed, 19 Jan 2011 08:42:40 -0800 Subject: New HS protocol To: Kadianakis George <desnacked(a)gmail.com> Cc: [redacted], [redacted], tor-assistants(a)torproject.org I wrote up the following new HS protocol on 2011-01-13, but haven't sent it out anywhere publicly visible yet. The only system I have come up with to hide a hidserv's identity key from the directory servers requires that the hidserv use a discrete-log cryptosystem for its identity key, and that the HS address contain enough of the identity key that a client can compute a scalar multiple of the identity key. (For example, the identity key can be a point on an elliptic curve in Weierstrass form, and the HS address can be the point's x coordinate.) The system designer chooses a group, an element P of prime order p in that group, and a publicly computable one-way function h mapping bitstrings to integers in the interval [1, p-1]. The HS chooses a secret key n and computes its public key nP; its descriptor index in time period t can be computed by any party which knows its public key as h(t | nP)*nP, but only the HS will know the discrete logarithm h(t | nP)*n of the descriptor index with base P. The HS can therefore compute an ECDSA signature, for example, which the directory server can verify using the descriptor index as a public key. Robert Ransom

1 0

Italy - third highest number users
by SiNA Rabbani 19 Sep '12

19 Sep '12

Somehow in August, Italy got a few thousand additional Tor users and became third as far as usage of Tor: > https://metrics.torproject.org/users.html?graph=direct-users&country=it#dir… > Country Mean daily users > United States 60769 (14.30 %) > Iran 43709 (10.28 %) > Italy 37306 (8.78 %) > Germany 36672 (8.63 %) Any insight? --SiNA

1 0

Reminder: Big/tricky/interesting features for 0.2.4 need proposals by 10 October
by Nick Mathewson 17 Sep '12

17 Sep '12

Hi, all! >From https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024 : "October 10, 2012: Big feature proposal checkpoint. Any large complicated feature which requires a design proposal must have its first design proposal draft by this date." There are only 23 days till October 10. If there's something you want in 0.2.4.x, and it is the kind of thing that needs a design proposal, and there is no proposal yet, it could be time to start writing! What needs a design proposal? Generally: anything that involves a change to the Tor protocol; anything whose security implications are nontrivial and need discussion; and anything that will change any Tor specification. Err on the side of "it needs a proposal." What is a "large complicated feature"? Please assume I'm going to be extremely grumpy here, and err on the side of "it is big". If the writeup of the proposal that explains how it works, or why to do it this way is going to take more than a few paragraphs, it is probably 'big' or 'complex'. (Note to would-be system-gamers: Please don't send a sketchy incomplete draft as a placeholder to get your foot in the door. That's not cool. If you don't have a draft ready, the feature can wait till 0.2.5.) (Note also: a feature proposal by this deadline is a necessary condition for getting your big/tricky/complicated feature into 0.2.4, but not a sufficient condition. It also needs to have a working implementation on schedule.) (Note finally: This is not a promise to not merge stuff that violates this deadline, but I sure will be trying not to merge such stuff.) yrs, -- Nick

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev September 2012