tor-dev July 2011

tor-dev@lists.torproject.org

22 participants
23 discussions

Thandy and what's next
by Tomas Touceda 13 May '12

13 May '12

Hello everyone, Thandy, for those who haven't heard about it by now, in few words is a package system for Tor packages and the like. One of the biggest problems we have right now is keeping users' Tor up to date, so we are trying to make time to get this going. (For more detailed information about Thandy check [1], specially the doc/ and specs/ directories) A couple of months ago, nickm and erinn worked in writing the package format spec (see [2] for more details), and now I'm going to start working as fast as I can (which may be slow) in implementing this last spec and get a working Thandy. On the more technical side, the idea is to implement this in Python as a first approach. In terms of distribution, Python isn't the best choice for platforms like Windows, but right now porting Thandy to another language isn't among the top priorities. This will probably be merged with the alpha track of releases we are making, so this can have as much testing as it can before going to stable. [1] https://gitweb.torproject.org/thandy.git/tree [2] https://gitweb.torproject.org/erinn/thandy.git/blob/934300a7c4c6c0493bedaf0… Cheers, -- Tomas Touceda Gentoo Developer - Qt, Scheme, Lisp

4 4

New paper by Goldberg, Stebila, and Ostaoglu with proposed circuit handshake
by Nick Mathewson 16 Jan '12

16 Jan '12

Crypto people who have been following threads about the circuit-establishment handshake will be interested in the new paper, "Anonymity and one-way authentication in key-exchange protocols", by Goldberg, Stebila, and Ostaoglu. Here's the version they updated today: http://www.cacr.math.uwaterloo.ca/techreports/2011/cacr2011-11.pdf If we're moving to an improved handshake, this might be a good candidate to consider. The protocol itself is on page 14. Some notes, written by a guy who knows less crypto than everybody involved: * It's a pure Diffie-Hellman based system, which would lend itself nicely to use with ECC. * It seems to require the same number of exponentiations as our current system, but Ian Goldberg notes that if you want to compute X^a and X^b at the same time you can do so more efficiently by taking into account the shared base. * The security proof requires that the Gap DH assumption holds over the group -- basically, that computing the Decisional DH problem is easy, but computing the Computational DH problem is hard. This assumption isn't true of most basic ECC groups -- I think it means you need to use a pairing-based system instead for the proof to hold. I'd bet that the authors aren't seriously suggesting that we use pairing-based crypto, but I'm wondering how much they were able to prove in a groups where DDH is hard. * I haven't read over the security model closely yet; folks should review it for reasonableness. * I'm hoping to write this up as a proposed spec soon, unless Ian or somebody wants to give it a shot. yrs, -- Nick

8 29

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

Proposal: Optimistic Data for Tor: Client Side
by Ian Goldberg 24 Sep '11

24 Sep '11

Sorry this took so long. As usual, things got inserted ahead of it in the priority queue. :-p Anyway, here's the client-side sibling proposal to the already-implemented 174. It cuts down time-to-first-byte for HTTP requests by 25 to 50 percent, so long as your SOCKS client (e.g. webfetch, polipo, etc.) is patched to support it. (With that kind of speedup, I think it's worth it.) Discuss. ;-) - Ian

4 9

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

Requesting feedback on TorDNSd v1.1
by LETO 02 Aug '11

02 Aug '11

Could some of you be so kind to try out my latest version of TorDNSd? It works a lot like ttdnsd with some additional features: - Filters to tell TorDNSd what requests to forward directly, forward through the SOCKS proxy or reject. - Remaps to define your own query replies (Currently only supports A, MX and NS replies) - Interactive shell (tordnsd-shell.exe): config-add settings and see them in action right away, will add extra features in the future. - Accepts both UDP and TPC DNS requests, forwards both through TCP requests - Basic caching of replies (optional) The rejects are handy to for example prevent leaking .onion requests (or any request if you want) You can also find some additional information about this release on my blog ( http://leto-r.blogspot.com/2011/07/tordnsd-v11-is-out.html ) It is written in C# and has been tested by myself under mono 2.6.7 / ubuntu natty. Check the default configuration @ https://raw.github.com/LETO-R/TorDNSd/b7aa04e980ad62308d4f2fa3143700c85b537… the full list of available settings. You can either download the mono compatible bins ( https://github.com/downloads/LETO-R/TorDNSd/tordnsd-v1.1-all-bin.zip ) or the windows installer ( https://github.com/downloads/LETO-R/TorDNSd/tordnsd-v1.1-win-setup.exe ) You can find the source code of these bins @ https://github.com/LETO-R/TorDNSd/tree/b7aa04e980ad62308d4f2fa3143700c85b53… sure to get the submodules too) The sourcecode should be compilable using either MonoDevelop 2.4.2 (using the mono runtime) or Visual Studio 2010. If you do not run it as root on a non-windows system, a fatal error is printed since TorDNSd will most likely not be able to bind on port 53. Specify --no-root to skip this check. Kind of feedback I'd like of you: - What OS did you try it on? When ran using mono, what version? - Did it work? Did it require the elevated rights (root / administrator)? Did the root-checking work on non-windows systems? - Did the shell work for you? If not, what issues did you notice? Any improvements that you suggest? - Are the settings explained well enough (check tordnsd.conf)? - Is the supplied default configuration sufficient? Any filter / remaps I forgot? - Any other feedback you can think of, don't hold back! This is my first attempt at a cross-platform .NET project that contains some non-windows specific code / workarounds (mostly for the shell) so I really could use the feedback. If you do not wish to run it as your main dns resolver 'just yet', you can always test it by using dig (examples: 'dig @127.0.0.1 bla.onion' to test rejection, or 'dig @127.0.0.1 vescum.tor' to test the remap feature) All I ask is to stay constructive. If you wonder, I constantly have TorDNSd (shell) running now and have configured it as my main dns resolver as I consider it secure. Hope you find this to be true as well. - LETO

3 5

[Patch] or/networkstatus.c
by Gisle Vanem 01 Aug '11

01 Aug '11

Hi list. In or/networkstatus.c there is a "#if 0" block inside the macro "SMARTLIST_FOREACH_JOIN". Not all compilers handle such contructs. In the prosess of making solution/projects file for "MS Visual C++ 2010 Express", I hit this problem (cl Version 16.00.30319.01). Can you please accept the following patch: diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c index 2586ce6..d8d6680 100644 --- a/src/or/networkstatus.c +++ b/src/or/networkstatus.c @@ -2001,19 +2001,25 @@ routers_update_status_from_consensus_networkstatus(smartlist_t *routers, routers_sort_by_identity(routers); + /* Since not all compilers handles '#' inside macros, we use a helper-macro. */ +#if 0 + #define CHECK_ROUTER_PURPOSE() do { \ + /* We have no routerstatus for this router. Clear flags and skip it. */ \ + if (!authdir) { \ + if (router->purpose == ROUTER_PURPOSE_GENERAL) \ + router_clear_status_flags(router); \ + } \ + } while (0) +#else + #define CHECK_ROUTER_PURPOSE() +#endif + SMARTLIST_FOREACH_JOIN(ns->routerstatus_list, routerstatus_t *, rs, routers, routerinfo_t *, router, tor_memcmp(rs->identity_digest, router->cache_info.identity_digest, DIGEST_LEN), + { CHECK_ROUTER_PURPOSE(); }) { -#if 0 - /* We have no routerstatus for this router. Clear flags and skip it. */ - if (!authdir) { - if (router->purpose == ROUTER_PURPOSE_GENERAL) - router_clear_status_flags(router); - } -#endif - }) { /* We have a routerstatus for this router. */ const char *digest = router->cache_info.identity_digest; ------------------------ --gv

2 2

Unused -v and -F options in torperf/trivsocks-client?
by David Fifield 30 Jul '11

30 Jul '11

Running "make" in torperf, I get errors about unused variables: $ make gcc -Wall -Werror -ggdb -c trivsocks-client.c trivsocks-client.c: In function ‘main’: trivsocks-client.c:452:51: error: variable ‘force’ set but not used [-Werror=unused-but-set-variable] trivsocks-client.c:452:21: error: variable ‘isVerbose’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make: *** [trivsocks-client.o] Error 1 The variables have to do with the -v and -F options, which appear not to do anything. This patch removes the options, but is it intentional? David Fifield

3 4

Improving Private Browsing Mode/Tor Browser
by Georg Koppen 29 Jul '11

29 Jul '11

After reading Mike's blog post and the material contained in it (via links) I thought it would be helpful to start a discussion about it. First of all thanks for explaining the idea of improving the private browsing mode. That aim seems worthwile but I want to focus more on the needs for high anonymity systems like Tor (I am one of the JonDos people to set the records straight). Thus, first I am not sure about the relationship of the improved private browsing and the anon mode. It seems like the former is kind of precondition of the latter and the latter adds some special anon features (or just layout stuff??): "We would love to be able to ship a vastly simplified browser extension that contains only a compiled Tor binary and some minimal addon code that simply "upgrades" the user's private browsing mode into a fully functional anonymous mode." What shall the upgrade do exactly? And why having again add-ons that can probably be toggled on/off and are thus more error-prone than just having an, say, Tor anon mode? Or is this already included in the Tor anon mode but only separated in the blog post for explanatory purposes? Sticking to the blog post (one of) its central idea seems to be to isolate the identifiers and state to the top-level domain in the URL bar as "activity in Tor Browser on one site should not trivially de-anonymize their activity [i.e. the activity of Tor users, G.K.] on another site to ad networks and exits". I am wondering whether this idea really helps here at least regarding exit mixes. If one user requests google.com, mail.google.com and other Google services within the 10 minutes interval (I am simplifying here a bit) without deploying TLS the exit is still able to connect the whole activity and "sees" which services that particular user is requesting/using. Even worse, if the browser session is quite long there is a chance of recognizing that user again if she happens to have the same exit mix more than once. Thus, I do not see how that helps avoiding linkability for users that need/want strong anonymity while surfing the web. Would be good to get that explained in some detail. Or maybe I am missing a point here. Now something to the proposed behavior of the referer and window.name. It is said that they should adhere to the "same-origin policy where sites from different origins get either no referer, or a referer that is truncated to the top-level domain". Assuming I understood TorButton's Smart-Spoofing option properly: Why is it not applied to the referer/window.name anymore? In other words: Why is the referer (and window.name) not kept if the user surfs within one domain (let's say from example.com to foo.example.com and then to foo.bar.example.com)? Before we implemented almost the same algorithm than Torbutton's smart-spoof algo in our own extension a while ago we had some compatibility issues (I remember yahoo.com that needed to have the referer untouched while surfing within the domain) that got fixed by it and never popped up again. Why stepping back? The idea "sites should also be allowed to request an exemption to this rule on a per-site basis using an html attribute, which could trigger a chrome permissions request, or simply be granted automatically (on the assumption that they could just URL smuggle the data)" seems rather awkward and not a good solution to a problem that is not really one. One final point: Leaving my previous section aside: Why is the referer and window.name not treated in the same way as cookies and others in the proposal. Why having two different policies for identifiers? I am not sure whether there could emerge some attacks out of that distinction but my feeling tells me that there should ideally be just one policy that governs all those identifiers. At least it would probably be easier to implement and to audit them. Georg

3 20

Report from the "Tor ecosystem" BoF at DebConf 11
by Jérémy Bobbio 28 Jul '11

28 Jul '11

Hi! Here is a report from DebConf 11, the annual conference of the Debian project. We had the opportunity to hold a "Tor ecosystem" BoF. It was short (we had only 45 minutes), but productive from my perspective. Here's an (obviously partial) report. A lot more people showed up (± 25) than we expected for a pure work meeting, so there is definitely an interest in having Tor and its ecosystem working well in Debian. Among the attendees we had: * Peter Palfrader, maintainer of the 'tor' package, * Ulises Vitulli, (co-)maintainer of 'vidalia', 'tor-arm', 'python-torctl', 'torchat', * Jérémy Bobbio, maintainer of 'torbutton', * intrigeri and bertagaz, developers of Tails (which is a live system based on Debian). A summary follows from some notes and memory. Feel free to correct me if you feel that things happened differently. New upstream packaging policy ============================= We took some time to discuss the changes to the packaging policy that were proposed by Andrew Lewman last June. See <https://lists.torproject.org/pipermail/tor-dev/2011-June/002780.html> Quoting the relevant part: GNU/Linux (deb and rpm) 1. tor-client. The same TBB we ship today. 2. tor-relay. Create tor-relay.(deb|rpm) that includes geoipdb and a pre-configured torrc that is for a non-exit relay. 3. tor-exit-relay. Create tor-exit-relay.(deb|rpm) that includes geoipdb and a pre-configured torrc that is for an exit relay. 4. tor-bridge. Create tor-bridge.(deb|rpm) that includes geoipdb and a pre-configured torrc that is for a bridge. The 'tor' source package in Debian already builds a binary package called 'tor-geoipdb' which contains GeoIP information. We have not even discussed about changing, as it is how it is supposed to be in Debian (pure data package as separate, architecture-independent packages). The proposed 'tor-client' and TBB in general was discussed later. For the rest, the hard part of the discussion also revolved around defining who are target users of these packages. Pure desktop users? People that can fiddle with a command-line and edit a configuration file? Experienced sysadmins? Having 3 different "configuration" packages for relays, exit-relays and bridges is something that could be done in Debian. But we had a rough consensus that it would actually complicate things for most Debian users. For bridges, pure desktop users would probably benefit from a better integration with Vidalia; so that made us rule out the need for a dedicated 'tor-bridge' package. Which left us with the "relay" and "exit relay" use cases and it looked like those could be better adressed by either a debconf question, or by some examples better integrated. Integration with other software, derivatives and custom distributions ===================================================================== While discussing how we could actually make it easier to setup relays, we got back to the lack of a way to source extra configuration files in `torrc`. We outlined some benefits that would have a `/etc/tor/torrc.d` directory full of configuration snippets: * The 'tor' package will not (or less) need patches to change the default settings. * It would make it much easier to implement example setups (relays, exit relays, bridges) either through a debconf question or through a system script like 'tor-setup-relay'. * Tails developers will only need to drop a very small extra configuration file instead of having to rewrite the whole, which should ease development and reviewing. * Other packages which need a hidden service to work (e.g. 'onioncat') would be able to create it automatically by installing the proper configuration snippet. That would enable them to work right after being installed. Feature request: https://trac.torproject.org/projects/tor/ticket/2863 Control of the system-wide 'tor' daemon ======================================= We finally have (currently in 'experimental') an easy way for applications to control the system-wide 'tor' daemon: the ControlSocket option is on by default. Vidalia, ARM and others now only require users to be in the system 'debian-tor' group to be able to control Tor. We did not have the time to properly discuss if, and how, we offer an easy way to add users to this group. Tor Browser Bundle (e.g tor-client) =================================== There is an incentive to have something as close as the Tor Browser Bundle in Debian. Otherwise, desktop users on Debian get a smaller anonymity set (such strong partitioning already happened in the past, see <http://bugs.debian.org/595375>). The main issue is the Tor fork of Firefox. There are a few possibilities on how it can be handled within Debian. Summary: this is doable, but requires a lot of work, and the cooperation of quite a few different parties. One other thing that TBB is doing is to start its own instance of Tor. We agreed that it was a behaviour that would be quite desirable to have. It will make setup even more easier and it might limit users exposure when they are not using Tor. In order to achieve that, we need either to make the 'tor' package not start Tor after being installed or we need a way have the `tor` binary without the rest of the daemon infrastructure (e.g initscript). The former will probably be quite confusing to sysadmins, so we agreed on splitting out the daemon binary from the current 'tor' package to a new 'tor-bin' package. How TorBrowser could get in Debian? =================================== Having a full separate source package for TorBrowser is not possible due to Debian Policy 4.13. But there are still other options, all having their shortcomings: 1. Make the 'iceweasel' source package (that's how Firefox is called in Debian due to trademark issues) produce an extra 'tor-browser' binary package. Issues: - Mike Hommey (iceweasel maintainer) stated clearly that he did not want to maintain the Tor patches. But we can probably settle on a policy like "if it does not build, just drop it". The removal of a binary package does not trigger NEW queue processing. It is also not triggered if the same binary packages returns before two weeks. - Double (?) the build time of 'iceweasel' which is already huge. Security team will not be happy, and it's going to be harder to actually maintain the TorBrowser side of things. Pros: until the patches do not apply anymore, it'll be less maintainance from our side. 2. Make the 'iceweasel' source package produce an extra binary package (e.g 'iceweasel-src') that will contain the full Iceweasel source. Create a 'tor-browser' package that Build-Depends on the former. Issues: - 'iceweasel' is a pretty fast moving target. This will need us to follow its uploads quite closely to ask for binNMU or to upload updated versions quickly. - The security team will have two packages to track instead of one. They might not like it at all. Pros: much easier for Mike Hommey and we are autonomous to upload the 'tor-browser' package if changes are only needed there. Looks like the latter is probably better. But it definitely needs to be checked with all parties involved first. For browser extensions curretly shipped with TBB, Debian already has 'torbutton' and 'noscript'. But we miss 'httpseverwhere' (#591579) and 'betterprivacy'. There are a few open issues that still need to be figured out: * TorBrowser should create dedicated profiles in the user home directories, * How can default values be set? Do we need 'locked down' preferences? * How should we handle other system-wide extensions? Active like for the main Iceweasel, totally ignored, or disabled by default? * If Debian ships the TorBrowser, should we prevent Torbutton from appearing in the usual Iceweasel? This will require a lot of work for the initial bootstrap and a decent amount of work for the daily maintainance after that. But it looked worthwhile anyhow… Cheers, -- Jérémy Bobbio .''`. lunar(a)debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev July 2011