tor-dev April 2011

tor-dev@lists.torproject.org

20 participants
15 discussions

Re: [tor-dev] Proposal 178: Require majority of authorities to vote for consensus parameters
by Nick Mathewson 27 Nov '11

27 Nov '11

On Tue, Feb 22, 2011 at 1:34 AM, Sebastian Hahn <hahn.seb(a)web.de> wrote: > Design: > > When the consensus is generated, the directory authorities ensure that > a param is only included in the list of params if at least half of the > total number of authorities votes for that param. The value chosen is > the low-median of all the votes. We don't mandate that the authorities > have to vote on exactly the same value for it to be included because > some consensus parameters could be the result of active measurements > that individual authorities make. This is possibly bikeshed, but I would suggest that instead of requiring half of existing authorities to vote on a particular parameter, we require 3 or more to vote on it. (As a degenerate case, fall back to "at least half" if there are fewer than 6 authorities in the clique.) I think we don't want the number to be _less_ than 3, since 3 is the smallest number of parties who can come up with a low-median that isn't just the diktat of a single member (1 party), or as low as either member wants it to be (2 parties). yrs, -- Nick

2 7

The Torouter project - where are we now?
by Runa A. Sandvik 24 Sep '11

24 Sep '11

Hi everyone, I am trying to figure out how we can move the Torouter project forward. In this email, I will try to summarize the current status of this project. The Torouter project has a total of four bugs in Trac. These are #2334, #2376, #2370 and #2596. #2334: Torouter on Buffalo breaks with large cached-descriptors[.new] files. The quick and easy solution here is to attach a USB stick to the router and use it as Tor's data directory. However, it would be great if someone could take a look at this and figure out a way to solve it. #2376: Torouter on OpenWrt shouldn't have its data directory in /tmp/. The problem with having Tor's data directory in /tmp is that whenever Torouter is rebooted, Tor generates new keys and gets a new fingerprint. There are a couple of different ways to solve this problem; Karsten suggested that we could modify OpenWrt to stop creating a /tmp partition. This probably means that we will have to ship our own OpenWrt image. I'm thinking that another option would be to modify the Tor-OpenWrt-package to use / as the data directory instead of /tmp. However, I wonder if 64M (no matter how it's partitioned) of space on the Buffalo router is insufficient as long as #2334 remains open. #2370: Torouter basic Web UI for OpenWrt. I haven't tried the web interface myself, but development seems to be moving along nicely. I'm not sure what the remaining steps are, other than packaging it as tor-ui (or similar) for OpenWrt. #2596: Figure out a better name than "torouter". Andrew thinks we should come up with a better name for this project, one that does not have "Tor" in the name. Suggestions? The Torouter project also has some open questions (some are mentioned on https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/Torouter as well): 1. How can we make sure that the version of Tor in OpenWrt is always up to date? Should we set up our own OpenWrt repository? Right now, the version of Tor in OpenWrt is 0.2.1.26. Also, should we offer packages for both stable and unstable? 2. We want to collect statistics, which means that we need to ship a GeoIP file as well. I'm thinking we should create a tor-geoipdb package for OpenWrt. Thoughts? 3. Do we want one Tor process for bridging and one for the transparent wifi network? I think this sounds good, if the router can handle it. If not, then just running a bridge is ok too. Have I missed anything important? Are there any other packages that we should include in OpenWrt? Other comments or suggestions? If you have more information or would like to help out, please let me know. Thanks, -- Runa A. Sandvik

8 16

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

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

28 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

GSoC - Torbutton for Thunderbird
by tagnaq 20 Apr '11

20 Apr '11

Hi, this is a reply to: https://lists.torproject.org/pipermail/tor-dev/2011-April/002551.html (I was not on the list at that point in time.) I wanted to let you know that I'm also researching in this area, but my goal is not to build an extension and I'm not involved in GsoC. I'm looking into issues that would negatively affect the pseudonymous use of Thunderbird with Tor. (Application level concerns when using Thunderbird with Tor) As a side effect I'm also playing around with Thunderbird/Lanikai. The outcome of my research (~08/2011) is hopefully useful to those actually implementing stuff. best regards, tagnaq

1 0

Orbot's inclusion of Privoxy (was: [tor-commits] r24630: {} adding binaries to res/raw folder (in projects/android/trunk/Orbot/res: . raw))
by Fabian Keil 17 Apr '11

17 Apr '11

Nathan Freitas <nathan(a)freitas.net> wrote: > Author: n8fr8 > Date: 2011-04-15 16:38:53 +0000 (Fri, 15 Apr 2011) > New Revision: 24630 > Log: > adding binaries to res/raw folder > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > > Added: projects/android/trunk/Orbot/res/raw/privoxy > =================================================================== > (Binary files differ) This seems to be (or based on) Privoxy 3.0.12 released in 2009. What's the rationale for not using a more recent version? Is this vanilla Privoxy or are there any custom patches? I get the impression that you are currently distributing the Privoxy binary as part of Orbot without even mentioning the license. Is that correct, or am I missing something? > Property changes on: projects/android/trunk/Orbot/res/raw/privoxy > ___________________________________________________________________ > Added: svn:executable > + * > Added: svn:mime-type > + application/octet-stream > > Added: projects/android/trunk/Orbot/res/raw/privoxy_config > =================================================================== > --- projects/android/trunk/Orbot/res/raw/privoxy_config (rev 0) > +++ projects/android/trunk/Orbot/res/raw/privoxy_config 2011-04-15 16:38:53 UTC (rev 24630) > @@ -0,0 +1,27 @@ > +# Generally, this file goes in /etc/privoxy/config > +# > +# Tor listens as a SOCKS4a proxy here: > +forward-socks4a / 127.0.0.1:9050 . Privoxy 3.0.12 already supports SOCKS5 which allows superior error messages in case of connection failures. Note that this requires the templates to be available and according to https://trac.torproject.org/projects/tor/ticket/2168 at least some of them aren't. > +confdir /data/data/org.torproject.android > +logdir /data/data/org.torproject.android > +# actionsfile standard # Internal purpose, recommended > +#actionsfile default.action # Main actions file > +#actionsfile user.action # User customizations > +#filterfile default.filter > + > +# Don't log interesting things, only startup messages, warnings and errors > +#logfile logfile > +#jarfile jarfile FEATURE_COOKIE_JAR shouldn't be supported in the vanilla 3.0.12 release. It has been removed in 3.0.11 due to being useless. > +#debug 1 > +#debug 0 # show each GET/POST/CONNECT request debug 0 has no effect. > +#debug 4096 # Startup banner and warnings > +#debug 8192 # Errors - *we highly recommended enabling this* > + > +#user-manual /usr/share/doc/privoxy/user-manual > +listen-address 127.0.0.1:8118 > +toggle 1 > +accept-intercepted-requests 1 Are the iptables rules used documented somewhere? Did you run into any issues with Privoxy on Android in general? Are the considerations that lead to the use of Privoxy documented somewhere? Thanks Fabian

2 2

Re: [tor-dev] [tor-commits] r24618: {website} Update Vidalia's project page (website/trunk/projects/en)
by Fabian Keil 14 Apr '11

14 Apr '11

Tomas Touceda <chiiph(a)gentoo.org> wrote: > Author: chiiph > Date: 2011-04-13 19:55:14 +0000 (Wed, 13 Apr 2011) > New Revision: 24618 > > Modified: > website/trunk/projects/en/vidalia.wml > Log: > Update Vidalia's project page > > Modified: website/trunk/projects/en/vidalia.wml > =================================================================== > --- website/trunk/projects/en/vidalia.wml 2011-04-13 18:58:21 UTC (rev 24617) > +++ website/trunk/projects/en/vidalia.wml 2011-04-13 19:55:14 UTC (rev 24618) > @@ -55,26 +55,26 @@ > - <a href="../dist/vidalia/vidalia-0.2.10.tar.gz">Source Tarball</a> > - (<a href="../dist/vidalia/vidalia-0.2.10.tar.gz.asc">sig</a>) > + <a href="../dist/vidalia/vidalia-0.2.12.tar.gz">Source Tarball</a> > + (<a href="../dist/vidalia/vidalia-0.2.12.tar.gz.sig">sig</a>) > </li> I'm having trouble locating the new signing key. Any pointers? Thanks. Fabian

3 3

Request for website commit review
by Robert Ransom 13 Apr '11

13 Apr '11

Please review Tor Subversion commits 24619, 24620, and 24621, then update the website. Regarding r24619: This change should be self-explanatory. Regarding r24620: I confirmed Robert Hogan's OpenPGP fingerprint on <https://trac.torproject.org/projects/tor/ticket/2883>. Regarding r24621: I obtained Tomás Touceda's OpenPGP fingerprint from his Tor LDAP account request on <https://trac.torproject.org/projects/tor/ticket/2621>, and I verified that the key with that fingerprint signed the Git tag vidalia-0.2.12 in <git://git.torproject.org/vidalia.git> and the release tarball at <https://www.torproject.org/dist/vidalia/vidalia-0.2.12.tar.gz>. I believe that these changes are appropriate, but they need to be reviewed before they are put onto The Tor Project's website. Robert Ransom

1 0

Redirecting network traffic to tor
by rp 08 Apr '11

08 Apr '11

Hi, I've become interested in one problem stated on tor web pages which deals with redirecting all traffic to tor (in windows). Redirecting traffic to tor seems to seek the goal of preventing traffic leaks. Openvpn does it's tunneling by rerouting all traffic to virtual network device and by changing dns resolver to the one on the remote tunnel side. Using openvpn's code, there is one possible way to prevent trafic leaks - by initializing fake route for all network traffic except for tor's, so only tor traffic can leave to the network. To try it, I have written simple .so library, that is linked to openvpn and uses openvpn code to manipulate routes (and possibly dns settings). Library gets loaded with tor using LD_PRELOAD and hooks connect and close calls on sockets. It works in the following way: 1) default route is overriden with fake one - now no traffic except dns can leave (assuming dns server is default gateway) 2) with each tor's connect, a route is added so traffic is routed through old route and not fake one, on close call the route is deleted - now only tor traffic and dns can leave 3) dns is set up to use tor's resolver - now only tor traffic will leave (assuming dns is properly redirected) 4) local connections fe. from web browser to local privoxy and from local privoxy to tor socks proxy are working, so this could be in principle used to help user with web browser gain more safety. The drawback is that to manipulate routes, one needs admin privileges. But this shouldn't be a problem - LD_PRELOAD way of doing things was the fastest to try this out. Although this is rather crude, it should prevent traffic leaks. What do you think about this? Could it be to some use? I have already tested all points except number 3), which would need more work, so before it I have to ask for your opinions - whether this is a waste of time or not. Please let me know. Roman PS: sorry for the noise with messages to various lists - i've got somewhat excited that there is a possibility for me to help with something useful..

2 1

Nick+Roger IRC chat time for developers, next Tuesday+Wednesday, 2-6pm eastern
by Nick Mathewson 08 Apr '11

08 Apr '11

Hi, all! Frequently, developers (including Nick and Roger) block on having both Nick and Roger online at the same time. We're trying to solve this by scheduling time to make sure that we're online and available to work with others on stuff that's blocking on is. We'll be on the development IRC channel (#tor-dev on OFTC) on March 8 and 9, from 1400 to 1800 EST (1900-2300 UTC, if I can add right). If you're doing something developmenty that's blocking on one or both of us, please stop by and have a chat. peace, -- Nick

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev April 2011