- tor-dev - lists.torproject.org

IPv6 Thoughts
by Lucky Green 16 May '11

16 May '11

I just read nickm's post on Tor IPv6 migration at https://blog.torproject.org/blog/ipv6-future-i-hear --- What needs to change Tor uses the Internet in many ways. There are three main ways that will need to change for IPv6 support, from most urgent to least urgent. Tor must allow connections from IPv6-only clients. (Currently, routers and bridges do not listen on IPv6 addresses, and can't advertise that they support IPv6 addresses, so clients can't learn that they do.) Tor must transport IPv6 traffic and IPv6-related DNS traffic. (Currently, Tor only allows BEGIN cells to ask for connections to IPv4 targets or to hostnames, and only allows RESOLVE cells to request A and PTR records.) Tor must allow nodes to connect to one another over IPv6. Allowing IPv6-only clients is the most important, since unless we do, these clients will be unable to connect to Tor at all. Next most important is to support IPv6 DNS related dependencies and exiting to IPv6 services. Finally, allowing Tor nodes to support a dual stack of both IPv4 and IPv6 for interconnection seems like a reasonable step towards a fully hybrid v4/v6 Tor network. --- One thought that may or may not be relevant to your sequence of implementation, but that you should be made aware of if you aren't already. (You may well be already be aware of it). The most important IPv6 compatibility task in Tor is that the Tor servers can accept inbound connections over IPv6. The second most important task is that Tor servers can make outbound IPv6 connections to services on the Internet. This is, and that may not be intuitive, not isomorphic with Tor clients being able to perform outbound connections to Tor servers over IPv6. Jane Tor User's laptop does, in all likelihood, not have a globally routable IP address. Instead, Jane's laptop has been assigned an RFC 1918 address by her cable modem or the NAT at the Internet cafe. It is Jane's cable modem that either does today or very soon will use an IPv6 address to communicate upstream. If the Tor server to which Jane is connecting does not support native IPv6, then Jane's provider will have to force her Tor traffic through a provider-level IPv6-to-IPv4 gateway. Some days that gateway will work well. Other days that proxy will be overloaded and won't work all that well. Both days, traffic latency will be increased unless the Tor server to which Jane connects accepts inbound IPv6. This talk by ARIN's CEO John Curran explains the issue beautifully. Watch from the 8 minute mark: http://www.youtube.com/watch?v=S3i4RRubCvI (When traffic has to be forced through a provider-level gateway out of technical necessity, obvious opportunities for easy filtering arise that I will not explore further in this post). In summary, outbound IPv6 Tor connections from end-users can wait until after Tor servers accept inbound IPv6 connections (and after exit nodes can make outbound IPv6 connections to other services). --Lucky

2 1

TorStatus
by Jan G. 16 May '11

16 May '11

Hey, im trying to port TorNetworkStatus to Ruby. I took a look at the Trac and it looks like it's project that should be done at the GSoC. https://trac.torproject.org/projects/tor/wiki/projects/TorStatus Is anyone working at this now? Greetings, J

3 2

Fairness between circuits
by Björn Scheuermann 12 May '11

12 May '11

Hi all, my group and I have recently been working on the question whether multiple circuits in Tor share the available bandwidth fairly and reasonably. What we found is: they don't. Not at all. First, we developed an analytical model for the fairness between circuits in an anonymity overlay, and thought about how to define fairness in a setting like Tor: when can the bandwidth sharing between many circuits in a complex anonymity overlay with varying available router bandwidth be called "fair"? In short: an adaptation of the max-min fairness concept does a very good job here. In order to overcome the existing fairness problems in Tor, we also developed a (surprisingly simple) mechanism which achieves max-min fairness without exchanging any additional data about the circuits between onion routers - the latter is clearly a nice trait with respect to privacy. We found that this approach goes very well with the recently proposed N23 congestion feedback scheme from the guys at Waterloo/Colorado/San Diego. We implemented Tor's scheduling mechanisms, the N23 extension, and our fairness mechanism in an event-based network simulator (ns-3). Independent from the question of inter-circuit fairness, we were able to confirm the key findings in the DefenestraTor tech report with respect to N23 based on this independent implementation. Moreover, we found that N23 does not solve the fundamental fairness problems - but N23 in combination with our fairness mechanism does an excellent job in this regard. We explain all this in much more detail in a paper: F. Tschorsch, B. Scheuermann: Tor is Unfair - and What to Do About It http://robotik.informatik.uni-wuerzburg.de/tr481.pdf We're hoping for feedback and vivid discussions - we would be really interested in bringing these mechanisms into Tor. Best regards Björn -- Prof. Dr. Björn Scheuermann Chair of Computer Science VII University of Würzburg Am Hubland, 97074 Würzburg, Germany Tel.: +49 931 31 85402 scheuermann(a)informatik.uni-wuerzburg.de http://www7.informatik.uni-wuerzburg.de

3 4

Re: [tor-dev] New paper by Goldberg, Stebila, and Ustaoglu with proposed circuit handshake
by Nick Mathewson 12 May '11

12 May '11

On Fri, May 6, 2011 at 11:12 AM, Ian Goldberg <iang(a)cs.uwaterloo.ca> wrote: > [+ Douglas, Berkant] > BTW, apologies to Berkant for misspelling his name!

1 0

regd throughput fingerprinting based attacks
by Prateek Mittal 11 May '11

11 May '11

Hi Roger, Hope things are going well. I wanted to point you to an updated version of our technical report on throughput-fingerprinting based attacks in Tor, available at https://netfiles.uiuc.edu/mittal2/www/throughput-fingerprinting.pdf. Thanks, Prateek

1 0

Orbot 1.0.5 Release Candidate
by Nathan Freitas 09 May '11

09 May '11

Based on feedback from our core test group in the Guardian Project, it seems like we have a solid new version of Orbot that includes Tor 0.2.2.25, as well as improved handling of transparent proxying. This new build also includes our own version of iptables, and proactively checks if the device has netfilter/owner support in the kernel. This should lead to overall less support requests from confused users who have "root" but still can't transproxy. We have a few UI tweaks to make, and need to make sure all of our translations are up-to-date, but otherwise, the app feels very ready to go. I invite any of you with a few spare cycles and an Android device handy to try it out if you haven't already. As this is a dev build, it is not signed by the official Tor distro key, so you will have to uninstall any existing Orbot official release. The final app we release to the market will be signed by the Tor key, and users will get an automatic "updates available" message from the Android market. https://guardianproject.info/downloads/0.2.2.25-orbot-alpha-1.0.5.20110508a… (.asc - signed by nathan(a)guardianproject.info 0xB374CBD2) If you aren't on our guardian-dev or -alpha lists, but are an Android user, then I encourage you to join, as we keep most of the day to day traffic on those lists: https://guardianproject.info/contact/ Best, Nathan

1 0

memcmp() & co. timing info disclosures?
by Marsh Ray 07 May '11

07 May '11

Greetings all, I happened to download the tor-0.2.2.25-alpha.tar.gz source yesterday and I noticed something. Apologies in advance if this has already been discussed and resolved, I did a cursory web search and didn't see anything. There are a lot of places in the code where memcmp() is called on memory buffers that look like they might contain various hashes or digests: ~/tor-0.2.2.25-alpha$ grep -r memcmp . | grep -i digest | wc -l 137 ~/tor-0.2.2.25-alpha$ grep -r memcmp . | grep -i key | wc -l 14 The built-in memcmp typically runs in time proportional to the common prefix of the two memory buffers being compared. In networked applications, this is often a significant source of timing information. Sometimes these are severe enough to result in disclosure of secret key material. A good resource for remote timing attacks is Nate Lawson's blog: http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/ Some cases look particularly concerning. For example, in the following code 'handshake_reply' appears to be supplied by the remote party and it is compared with something called "key material". src/or/onion.c:331: if (memcmp(key_material, handshake_reply+DH_KEY_LEN, DIGEST_LEN)) { /* H(K) does *not* match. Something fishy. */ log_warn(LD_PROTOCOL,"Digest DOES NOT MATCH on onion handshake. " "Bug or attack."); goto err; } In the worst-case, the attacker could simply supply different values of handshake_reply, observe how long each takes to compare, and figure out the value of key_material statistically byte-by-byte. Perhaps this key material is never used again, or there are other reasons this timing informaion is not useful. But in general, it's very difficult to determine whether or not such a timing info disclosure represents a vulnerability or how difficult it would be to exploit. Expert programmers seem to consistently underestimate the severtiy of these weaknesses, perhaps because they are so subtle. I've just started learning about Tor so it's not possible for me to review every instance. I think the quickest and easiest solution would be to replace every usage of memcmp and str*cmp in the source with an alternate version that guarantees a constant time comparison. I'd expect this could be done with negligible performance impact, especially for short comparisons like 20-byte hash values. Regards, - Marsh

5 15

Mingw ann non-autoconf build
by Gisle Vanem 04 May '11

04 May '11

I have a question regarding src/win32/orconfig.h. I guess this hand- edited file is supposed to be used by MSVC (targeting Win32, WinCE and whatnot). Or? What prevents it from being used by e.g. MingW in a non- autoconf build? If someone (like me that doesn't want to touch autotool with a ten-feet pole) want to use this file unchanged, things like: #undef HAVE_SYS_TIME_H has to be treated specifically for MingW. E.g.: #ifndef __MINGW32__ #undef HAVE_SYS_TIME_H #endif Same goes for HAVE_UNISTD_H, HAVE_GETTTIMEOFDAY etc. BTW. Older MingW does not have gettimeofday(). I'm not sure when the function was added. So to be perfect, an "#ifndef" test should consider the __MINGW32_VERSION too. --gv For every credibility gap, there is a gullibility fill.

3 3

Moving Orbot to Git from SVN
by Nathan Freitas 02 May '11

02 May '11

Sebastian, I believe you are the one to request this of. We need this repo/path: https://svn.torproject.org/svn/projects/android/trunk/Orbot/ moved over to a repo on the git server, as soon as you can. I am also not sure of my credential status on the git server, whether they are the same as Trac and SVN or not. It should have happened a long time ago, but now GSoC 2011 is acting as a catalyst, such that we can properly have our student branch his work. Best, Nathan

2 1

Fwd: Re: [guardian-dev] ORBot Alpha, some candles, a few glasses of wine and a packet sniffer
by Nathan Freitas 29 Apr '11

29 Apr '11

fyi -------- Original Message -------- Subject: Re: [guardian-dev] ORBot Alpha, some candles, a few glasses of wine and a packet sniffer Date: Wed, 27 Apr 2011 14:49:01 -0700 From: Nathan of Guardian <nathan(a)guardianproject.info> Organization: The Guardian Project To: guardian-dev(a)lists.mayfirst.org CC: tor-dev(a)lists.torproject.org Fantastic, Manuel. Looks like we are going to need some wine over to patch this up. This type of look at how our transproxy all rules are working (or not) is long overdue. I really appreciate your effort. The first thing that comes to mind is that we are setting up the iptables rules on an app-by-app basis, using the list of user IDs we are provided by Android API calls. It is quite possible that certain subsystems are not represented in that list. There may be a better way to implement the transproxy all implementation that is more of a "everything but tor" approach. Our transproxy configuration is based on the approach outlined here: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentPro… We'll have to go through additional recommended configurations that we are not addressing in our current "all" setup, and see if they address the leakage you have found. Best, Nathan On 04/27/2011 12:40 PM, Manuel wrote: > Hi all! > > Mini-intro: Hi, I'm Manuel (aka __sporkbomb), infosec researcher from > Austria, got bored and asked Nathan if he wanted help with ORBot ;) > > Setup: Simply an open AP, a Desire HD running CM 7.0.2 and > 0.2.2.22-orbot-alpha-1.0.5.20110417a-dev plus airodump. > > Methodology: The dump was started after the tor connection (and full > transproxying) was established in order to reduce false positives. Total > dump length is around 3h15m, around 57MB of data. Of course the phone > was left idle for a quite a while, also to ensure that it didn't do > nasty untorified stuff when waking up to check mails. Afterwards, I used > Wireshark's 'Endpoints' statistics function to determine all TCP > endpoints in the dump[0] and awk'd & uniq'd the IPs out of it[1]. As the > next step, I determined which of these IPs was in my cached-consensus[2] > (somewhat ill-advised, because I compared with my laptop's > cached-consensus rather than the phone's, causing two false positives > [false non-tor nodes] that actually were nodes). I also ran a reverse > lookup on all IPs [3]. As the last step, I went through all > communication with IPs that were not found in cached-consensus[4]. > > You can find links to most of the files I produced at the end of this > mail, excluding the dump, which I can provide if requested, but would > rather not hand out publicly (mostly because of the size). > > All in all, the phone connected to 88 IPs during that time. 37 of those > were not contained in the laptop's cached-consensus, two of which were > actually legitimate nodes (according to metrics.torproject.org) that > just went down throughout the duration of the test, leaving us with 35 > non-Tor IPs. They can be categorized as follows: > > - 27 of those nodes had no other communication than multiple TCP > packets, sometimes from a few different source ports (i.e. different TCP > connections), all originating from the phone and having FIN+PSH+ACK set. > (PSH is the 'push flag', which requests that this data bypass buffers > and be handed directly to the application) > > - 4 existing connections that still transmitted data; one even contained > Market HTTP (cleartext) API requests. > > - 4 were completely unencrypted and newly established connections to > YouTube or Revision3 video servers. This one is rather bad - it seems > that the video player subsystem of Android ignores the proxy setting and > leaks everything, including DNS. I also mentioned this yesterday on > Twitter, but didn't want to post it yet without confirmation, but it's > definitely reproducible on my end. > > -------------------- > Sumup of this part: Generally solid performance, but already established > connections might pose a threat (a minor one I'd guess, however...unless > one of you can think of a scenario where that causes Bad Things to > happen?). Additionally, the video player completely ignores the proxy > setting and communicates untorified. While video streaming isn't a > strong point of Tor anyway, it's still not good...does anyone have good > contact to CyanogenMod people and can ask about that one? > > Various tidbits of slight UX annoyances plus a few suggestions: > - ORBot ignores the "Transparent proxy" setting when connecting, I > always have to enter the Settings menu, untick and re-tick "Transparent > proxying" and press back to actually cause it to be enabled. > - Related to this: Is it possible to colour-code the "Transparent > proxying {DIS,EN}ABLED" notification? The bug above might have serious > consequences, because if someone doesn't visit check.torproject.org to > assure that he/she is actually torified, chances are that he/she will > browse in clear. DISABLED and ENABLED are only three characters away > from each other, whereas a red vs green notification would probably > catch the eye. > - Install fails when installing/uncompressing tor binary > https://trac.torproject.org/projects/tor/ticket/2989 [turns out that > this is only a bug on Android<2.3, but still...see comment #1 for more > details] > - Blank semi-permanent status box > https://trac.torproject.org/projects/tor/ticket/2993 [haven't updated > this one yet; the bug actually occured only before the first reboot for > me, and one time afterwards when I had b0rked the network badly] > - ORBot vs DroidWall: Starts with 'You don't preserve my chains like you > used to :(' and ends with, if I remember correctly, ORBot flushing > iptables rules. I'll have a look at that one tomorrow (or is there > already some data on it?). > > For now, have a nice evening! > > Cheers, > > __sporkbomb > > > > > > [0] http://sporkbomb.eu/orbot/endpoints > [1] http://sporkbomb.eu/orbot/ips > [2] http://sporkbomb.eu/orbot/inconsensus (result of a grep -c - IPs > with '0' in the second field are not contained in the consensus) > [3] http://sporkbomb.eu/orbot/dig-result > [4] http://sporkbomb.eu/orbot/not-inconsensus.notes > _______________________________________________ > Guardian-dev mailing list > > Post: Guardian-dev(a)lists.mayfirst.org > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > To Unsubscribe > Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org > Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… > > You are subscribed as: nathan(a)guardianproject.info _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

3 2