June 2011 - tor-dev - lists.torproject.org

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

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

Tor and BGP integration
by Jacob Appelbaum 29 Jun '11

29 Jun '11

Hello from Iceland, Linus invited me to Reykjavik to talk about Tor at the NORDUnet conference and this idea is the result of a bit of feedback from some network operators here. Tor needs a way to be friendly to large network operators who wish to enable exiting to anonymous communication for their networks. These network operators are happy to allow anyone to pass traffic to their relays as entry nodes, middle nodes and even limited exit nodes. Linus and I have been discussing methods of automating this process and of course BGP integration makes a lot of sense. Generally, a network operator has a set of AS numbers for their network blocks and as they want people to connect to many of their services, it helps quite a bit to allow exiting to those services from their own Tor relays. We came up with two main ideas for making this happen. One method would be to write a program where given an AS number and a BGP feed, we parse all of the advertised network blocks and emit exit policy lines that accepts all traffic for the AS. This would allow for a web service similar to BulkExitList.py for network aware exit policy generation and relay operators would simply need to add this to their Tor configs manually. For mostly static networks, a cronjob would be fine and Tor doesn't need to know about AS numbers internally. Another method would be to write a controller that watches for BGP network updates and Tor would add relevant exit policy lines for any configured AS. This would allow any Tor relay to dynamically learn about network changes if it has access to a BGP feed patched into a controller. This could be implemented by adding some configuration options to Tor that let Tor know which AS numbers matter to which router. It may also allow for the router to auto learn it's own likely family network but it lacks any kind of bi-directional confirmation, still it seems useful information to have... It would be fantastic if someone offered a hidden service NORDUNet BGPMon feed. This would help enable the first method of generating network aware exit policies; this would also help with the development of AS awareness in Tor itself. In the future, I imagine that it makes a lot of sense for circuit building to be BGP aware as mere netblocks will not be very useful in an ipv6 world, they're already mostly irrelevant. Anyway, food for thought. Linus and I will probably hack on some of these ideas in the near future. All the best, Jake

6 9

WIN32_WINNT in or/or.h
by Gisle Vanem 27 Jun '11

27 Jun '11

I think that the values for 'WIN32_WINNT' and '_WIN32_WINNT' should be protected against redefinement. Reason: In order for MingW to prototype getaddrinfo() and freeaddrinfo() correctly (in <ws2tcpip.h>), '_WIN32_WINNT' *must* be defined as 0x0501 or higher. or/or.h blindly defines them as 0x0400. So, building with -DHAVE_GETADDRINFO needs _WIN32_WINNT to be set to 0x0501. As of now, MingW would simply fallback to use gethostbyname(). So I think this little patch is in order: --- ..\Git-latest\src\or\or.h Mon Jun 20 23:58:06 2011 +++ or\or.h Tue Jun 21 00:04:42 2011 @@ -23,8 +23,12 @@ #endif #ifdef MS_WINDOWS +#ifndef WIN32_WINNT #define WIN32_WINNT 0x400 +#endif +#ifndef _WIN32_WINNT #define _WIN32_WINNT 0x400 +#endif #define WIN32_LEAN_AND_MEAN #endif ----------------------------- What do you say? --gv

2 2

Proposal 182: Credit Bucket
by Nick Mathewson 27 Jun '11

27 Jun '11

Here's a proposal by Florian and Björn about improving our queueing times. Per usual procedure, I'm sending it here as I put it in the proposals directory. Filename: 182-creditbucket.txt Title: Credit Bucket Author: Florian Tschorsch and Björn Scheuermann Created: 22 Jun 2011 Status: Draft Overview: The following proposal targets the reduction of queuing times in onion routers. In particular, we focus on the token bucket algorithm in Tor and point out that current usage unnecessarily locks cells for long time spans. We propose a non-intrusive change in Tor's design which overcomes the deficiencies. Motivation and Background: Cell statistics from the Tor network [1] reveal that cells reside in individual onion routers' cell queues for up to several seconds. These queuing times increase the end-to-end delay very significantly and are apparently the largest contributor to overall cell latency in Tor. In Tor there exist multiple token buckets on different logical levels. They all work independently. They are used to limit the up- and downstream of an onion router. All token buckets are refilled every second with a constant amount of tokens that depends on the configured bandwidth limits. For example, the so-called RelayedTokenBucket limits relay traffic only. All read data of incoming connections are bound to a dedicated read token bucket. An analogous mechanism exists for written data leaving the onion router. We were able to identify the specific usage and implementation of the token bucket algorithm as one cause for very high (and unnecessary) queuing times in an onion router. We observe that the token buckets in Tor are (surprisingly at a first glance) allowed to take on negative fill levels. This is justified by the TLS connections between onion routers where whole TLS records need to be processed. The token bucket on the incoming side (i.e., the one which determines at which rate it is allowed to read from incoming TCP connections) in particular often runs into non-negligible negative fill levels. As a consequence of this behavior, sometimes slightly more data is read than it would be admissible upon strict interpretation of the token bucket concept. However, the token bucket for limiting the outgoing rate does not take on negative fill levels equally often. Consequently, it regularly happens that somewhat more data are read on the incoming side than the outgoing token bucket allows to be written during the same cycle, even if their configured data rates are the same. The respective cells will thus not be allowed to leave the onion router immediately. They will thus necessarily be queued for at least as long as it takes until the token bucket on the outgoing side is refilled again. The refill interval currently is, as mentioned before, one second -- so, these cells are delayed for a very substantial time. In summary, one could say that the two buckets, on the incoming and outgoing side, work like a double door system and frequently lock cells for a full token bucket refill interval length. General Design: In order to overcome the described problem, we propose the following changes related to the token bucket algorithm. We observe that the token bucket on the outgoing connections with its current design is contra productive in the sense of queuing times. We therefore propose modifications to the token bucket algorithm that will eliminate the "double door effect" discussed above. Let us start from Tor's current approach: Thus, we have a regular token bucket on the reading side with a certain rate and a certain burst size. Let x denote the current amount of tokens in the bucket. On the outgoing side we need something appropriate that monitors and constrains the outgoing rate, but at the same time avoids holding back cells (cf. double door effects) whenever possible. Here we propose something that adopts the role of a token bucket, but realizes this functionality in a slightly different way. We call it a "credit bucket". Like a token bucket, the credit bucket also has a current fill level, denoted by y. However, the credit bucket is refilled in a different way. To understand how it works, let us look at the possible operations: As said, x is the fill level of a regular token bucket on the incoming side and thus gets incremented periodically according to the configured rate. No changes here. If x<=0, we are obviously not allowed to read. If x>0, we are allowed to read up to x bytes of incoming data. If k bytes are read (k<=x), then we update x and y as follows: x = x - k (1) y = y + k (2) (1) is the standard token bucket operation on the incoming side. Whenever data is admitted in, though, an additional operation is performed: (2) allocates the same number of bytes on the outgoing side, which will later on allow the same number of bytes to leave the onion router without any delays. If y + x > -M, we are allowed to write up to y + x + M bytes on the outgoing side, where M is a positive constant. M specifies a burst size for the outgoing side. M should be higher than the number of tokens that get refilled during a refill interval, we would suggest to have M in the order of a few seconds "worth" of data. Now if k bytes are written on the outgoing side, we proceed as follows: If k <= y then y = y - k In this case we use "saved" credits, previously allocated on the incoming side when incoming data has been processed. If k > y then y = 0 and x = x - (k-y) We generated additional traffic in the onion router, so that more data is to be sent than has been read (the credit is not sufficient). We therefore "steal" tokens from the token buffer on the incoming side to compensate for the additionally generated data. This will result in correspondingly less data being read on the incoming side subsequently. As a result of such an operation, the token bucket fill level x on the incoming side may become negative (but it can never fall below -M). If y + x <= -M then outgoing data will be held back. This may lead to double-door effects, but only in extreme cases where the outgoing traffic largely exceeds the incoming traffic, so that the outgoing bursts size M is exceeded. Aside from short-term bursts of configurable size (as with every token bucket), this procedure guarantees that the configured rate may never be exceeded (on the application layer, that is; as with the current implementation, an attacker may easily cause the onion router to arbitrarily exceed the limits on the lower layers). Over time, we never send more data than the configured rate: every sent byte needs a corresponding token on the incoming side; this token must either have been consumed by an incoming byte before (it then became a "credit"), or it is "stolen" from the incoming bucket to compensate for data generated within the onion router. Specific Design Changes: In the following we briefly point out the specific changes that need to be done in Tor's source code. By doing so one can see how non intrusive our modifications are. First we need to address the bucket increment and decrement operations. According to the described logic above, this should be done in the methods connection_bucket_refill and connection_buckets_decrement respectively. In particular allocating, saving and "stealing" of tokens need to be considered here. Second the rate limiting, i.e. the amount we are allowed to write (connection_bucket_write_limit) needs to be adapted in lines of the credit bucket logic. Meaning in order to avoid the here identified unnecessary queuing of cells, we need to consider the new burst parameter M. Here we also need to take non rate limited connections such as from the localhost into account. The rate limiting on the reading side remains the same. At last we need to find good values/ ratios for the parameter M such that the trade off between avoiding "double door effects" and maintaining strict rate limits work as expected. As future work and after insights about the performance gain of the here described proposal we need to find a way to implement this both using bufferevent rate limiting with libevent 2.3.x and Tor's rate limiting code. Conclusion: This proposal can be implemented with moderate effort and requires changes only at the points where currently the token bucket operations are performed. We feel that this is not the be-all and end-all solution, because it again introduces a feedback loop between the incoming and the outgoing side. We therefore still hope that we will be able to come to a both simpler and more effective design in the future. However, we believe that what we proposed here is a good compromise between avoiding double-door effects to the furthest possible extent, strictly enforcing an application-layer data rate, and keeping the extent of changes to the code small. Feedback is highly appreciated. References: [1] Karsten Loesing. Analysis of Circuit Queues in Tor. August 25, 2009. [2] https://trac.torproject.org/projects/tor/wiki/sponsors/SponsorD/June2011

1 0

Reg : using the keep alive messages
by Sambuddho Chakravarty 27 Jun '11

27 Jun '11

Hi All I read in the Tor design spec that Tor control protocol supports keepalive messages which could be used for link padding . I wonder if anyone has ever explored using them... Thanks Sambuddho

2 4