- tor-dev - lists.torproject.org

سلام برنامه تور فارسی برای ایران می خواستم
by Mohammad Mo 29 Sep '11

29 Sep '11

سلام برنامه تور فارسی برای ایران می خواستم ولی تاحالا هیچ جوابی به فارسی دریافت نکرده ام

1 0

Proposed addition to Proposal 179
by Tim Wilde 28 Sep '11

28 Sep '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey All, In some recent research we came across another easily-fingerprintable attribute of the Tor TLS handshake, so I would like to propose this addition to Proposal 179: https://github.com/twilde/torspec/commit/c202230b40c72cbdbe43bbda9cc1a7caad… Or, if in my git-newb-ish-ways I represent this correctly: git://github.com/twilde/torspec.git@c202230b40 Short summary: we should send an SSL Session ID, even if we don't track it or ever use it (which I wouldn't suggest we do) because not sending one makes us stick out like a sore thumb. :) Apologies if my git-newb-ish-nes makes this more difficult to grab, pointers welcome (I may be a git newb but I'm totally in love with it, mmm, sexy VCS :)). Thanks, Tim - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde(a)cymru.com | +1-847-378-3333 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk6DkC0ACgkQluRbRini9tgfGACeKF41vKvoOvGFEHq5JXU9/u38 RWsAn1mb6MX0gvut6/ROYl0Kg6NQoF/e =2PWa -----END PGP SIGNATURE-----

1 0

Dynamic Throttling in Tor
by Rob Jansen 27 Sep '11

27 Sep '11

Hello, We've been exploring dynamic algorithms for throttling Tor clients. We've come up with three algorithms that are easier to maintain than static throttling (i.e. don't need to be reconfigured often), and produce significant performance benefits for web clients at the expense of bulk clients. Details are available in our technical report: http://www-users.cs.umn.edu/~jansen/papers/throttling-umntr11-019.pdf We are looking for feedback and are wondering if these algorithms look useful to Tor. They have already been implemented, and patches can be prepared if there is interest. Best regards, Rob -- Rob G. Jansen U.S. Naval Research Laboratory rob.g.jansen(a)nrl.navy.mil 202.767.2389

1 0

Re: [tor-dev] MITM for TOR
by andrew＠torproject.org 26 Sep '11

26 Sep '11

On Fri, Sep 23, 2011 at 03:52:25PM +0200, robvanderhoeven(a)ziggo.nl wrote 0.5K bytes in 20 lines about: : I build a small Monitor In The Middle (MITM) proxy that can be used to : study the communication between TOR and the browser. Hope this can be : used to improve TOR. : : It's small but quite powerful. Wrote an article about it on my blog: : : http://freedomboxblog.nl/mitm-for-tor/ It seems you responded to another thread with a new subject, perhaps this has confused others. How does this differ from the tamper data extension in Firefox? https://addons.mozilla.org/en-US/firefox/addon/tamper-data/ In either case, did you find anything in the interaction between firefox and the Tor socks proxy? From you blog post, it looks like Tor socks interaction is quick, and the performance of everything else is dependent on the active circuit. And, it's Tor, not TOR. See https://www.torproject.org/docs/faq.html.en#WhyCalledTor for the details. -- Andrew pgp key: 0x74ED336B

2 2

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

Re: [tor-dev] Proposal 185: Directory caches without DirPort
by Karsten Loesing 23 Sep '11

23 Sep '11

Looks like we lost tor-dev somewhere. Quoting Nick's reply without cutting out stuff I have no comments to. On 9/22/11 10:16 PM, Nick Mathewson wrote: > On Thu, Sep 22, 2011 at 4:49 AM, Karsten Loesing > <karsten.loesing(a)gmx.net> wrote: >> Hi Nick, >> >> and here are a few comments to your proposal 185: >> >> On 9/20/11 9:34 PM, Nick Mathewson wrote: >>> Configuration: >>> >>> Add a new torrc option, "DirCache". Its values can be "0", "1", >>> and "auto". If it is 0, we never act as a directory cache, even >>> if DirPort is set. >> >> Do these relays set "dir-cache 0" in their router descriptors? Or do >> they just not include "dir-cache 1"? > > They just do not include "dir-cache 1". I'll make this more explicit. > >> But if they set a non-zero >> DirPort, how will the directory authorities and clients know that the >> node doesn't want to act as a directory cache? > > If you don't want to act as a directory cache, you don't publish DirPort. > > "dir-cache 0" wouldn't work to disable a dirport published in your > "router" line, since old Tors wouldn't recognize the dir-cache option, > and so wouldn't know that they weren't supposed to use DirPort. > >> >>> If it is 1, then we act as a directory cache >>> according to same rules as those used for nodes that set a >>> DirPort. If it is "auto", then Tor decides whether to act as a >>> directory cache. >> >> What are the rules when setting a DirPort? Successful self-test and >> minimum advertised bandwidth? > > I believe so, except of course you don't need to have a reachable > DirPort in this case. > >> How's "1" different from "auto" if Tor >> decides whether to act as a directory cache in both cases? > > "1" is "I want to be a directory cache"; "auto" is "use me as a > directory cache if that would help". I think that auto might be in > the future be more adaptive, depending on the state of the network and > the number of directory caches. > > I would like "DirCache auto" to be something we're comfortable making > the new default. > >>> Consensus: >>> >>> Authorities should assign a "DirCache" flag to all nodes running >>> as a directory cache that do not set a DirPort. >> >> Would it make sense to have them assign the "DirCache" flag for nodes >> with a non-zero DirPort, too? > > IMO that would just use up space. Is there an argument in favor? Yup, I agree with you that it uses up space. My thinking was that clients wouldn't have to check two things (non-zero Dir port or DirCache flag) to learn whether a relay has directory info for them, but just one thing. And it could lead to some confusion when people try to understand dir-spec.txt or the TorStatus output (once it displays this flag). Not very strong arguments though. I also wasn't certain if the proposal was wrong here and you really meant that the flag would be assigned to all directory caches. If the proposal says what you meant, carry on. :) Best, Karsten

2 1

Proposal 184: Miscellaneous changes for a v3 Tor link protocol
by Nick Mathewson 23 Sep '11

23 Sep '11

Filename: 184-v3-link-protocol.txt Title: Miscellaneous changes for a v3 Tor link protocol Author: Nick Mathewson Created: 19-Sep-2011 Status: Open Target: 0.2.3.x Overview: When proposals 176 and 179 are implemented, Tor will have a new link protocol. I propose two simple improvements for the v3 link protocol: a more partitioned set of which types indicate variable-length cells, and a better way to handle link padding if and when we come up with a decent scheme for it. Motivation: We're getting a new link protocol in 0.2.3.x, thanks (again) to TLS fingerprinting concerns. When we do, it'd be nice to take care of some small issues that require a link protocol version increment. First, our system for introducing new variable-length cell types has required a protocol increment for each one. Unlike fixed-length (512 byte) cells, we can't add new variable-length cells in the existing link protocols and just let older clients ignore them, because unless the recipient knows which cells are variable-length, it will treat them as 512-byte cells and discard too much of the stream or too little. In the past, it's been useful to be able to introduce new cell types without having to increment the link protocol version. Second, once we have our new TLS handshake in place, we will want a good way to address the remaining fingerprinting opportunities. Some of those will likely involve traffic volume. We can't fix that easily with our existing PADDING cell type, since PADDING cells are fixed-length, and wouldn't be so easy to use to break up our TLS record sizes. Design: Indicating variable-length cells. Beginning with the v3 link protocol, we specify that all cell types in the range 128..255 indicate variable-length cells. Cell types in the range 0..127 are still used for 512-byte cells, except that the VERSIONS cell type (7) also indicates a variable-length cell (for backward compatibility). As before, all Tor instances must ignore cells with types that they don't recognize. Design: Variable-length padding. We add a new variable-length cell type, "VPADDING", to be used for padding. All Tor instances may send a DROP cell at any point that a VERSIONS cell is not required; a VPADDING cell's body may be any length; the body of a VPADDING cell MAY have any content. Upon receiving a VPADDING cell, the recipient should drop it, as with a PADDING cell. Interaction with proposal 176: Proposal 176 says that during the v3 handshake, no cells other than VERSIONS, AUTHENTICATE, AUTH_CHALLENGE, CERT, and NETINFO are allowed, and those are only allowed in their standard order. If this proposal is accepted, then VPADDING cells should also be allowed in the handshake at any point after the VERSIONS cell. They should be included when computing the "SLOG" and "CLOG" handshake-digest fields of the AUTHENTICATE cell. Notes on future-proofing: It may be in the future we need a new cell format that is neither the original 512-byte format nor the variable-length format. If we do, we can just increment the link protocol version number again. Right now we have 10 cell types; with this proposal and proposal 176, we will have 14. It's unlikely that we'll run out any time soon, but if we start to approach the number 64 with fixed-length cell types or 196 with var-length cell types, we should consider tweaking the link protocol to have a variable-length cell type encoding.

3 2

Proposal 185: Directory caches without DirPort
by Nick Mathewson 22 Sep '11

22 Sep '11

Filename: 185-dir-without-dirport.txt Title: Directory caches without DirPort Author: Nick Mathewson Created: 20-Sep-2011 Status: Open Overview: Exposing a directory port is no longer necessary for running as a directory cache. This proposal suggests that we eliminate that requirement, and describes how. Motivation: Now that we tunnel directory connections by default, it is no longer necessary to have a DirPort to be a directory cache. In fact, bridges act as directory caches but do not actually have a DirPort exposed. It would be nice and tidy to expand that property to the rest of the network. Configuration: Add a new torrc option, "DirCache". Its values can be "0", "1", and "auto". If it is 0, we never act as a directory cache, even if DirPort is set. If it is 1, then we act as a directory cache according to same rules as those used for nodes that set a DirPort. If it is "auto", then Tor decides whether to act as a directory cache. Advertising cache status: Nodes which are running as a directory cache but which do not have a DirPort set should set the entry "dir-cache 1" in their router descriptors. Consensus: Authorities should assign a "DirCache" flag to all nodes running as a directory cache that do not set a DirPort. This does not require a new version of the consensus algorithm.

3 2

connection_edge_process_relay_cell(): data cell dropped, unknown stream
by Fabian Keil 22 Sep '11

22 Sep '11

While experimenting with Tor v0.2.3.4-alpha's "optimistic data" and thus keeping an eye on the logs, I noticed that I get a lot of the following messages (with and without "optimistic data"): Sep 20 13:47:57.428 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8236 relay cells here (command 2, stream 49411). Sep 20 13:47:57.428 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 911. Sep 20 13:47:57.428 [info] {APP} connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 49411). Sep 20 13:47:57.431 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8237 relay cells here (command 2, stream 49411). Sep 20 13:47:57.431 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 910. Sep 20 13:47:57.431 [info] {APP} connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 49411). Sep 20 13:47:57.432 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8238 relay cells here (command 2, stream 49411). Sep 20 13:47:57.432 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 909. Sep 20 13:47:57.432 [info] {APP} connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 49411). Sep 20 13:47:57.432 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8239 relay cells here (command 2, stream 49411). [...] Sep 20 13:48:01.479 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8379 relay cells here (command 2, stream 49411). Sep 20 13:48:01.479 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 968. Sep 20 13:48:01.479 [info] {APP} connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 49411). Sep 20 13:48:01.479 [debug] {APP} relay_lookup_conn(): found conn for stream 49410. Sometimes up to 400-500 dropped cells per unknown stream id. The deliver window seems to go down to 900 and then starts at 999 again. It's my impression that it always happens after the client connection is closed prematurely, something my feed reader unfortunately does frequently: Sep 20 13:47:56.608 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8235 relay cells here (command 2, stream 49411). Sep 20 13:47:56.608 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 912. Sep 20 13:47:56.792 [debug] {APP} circuit_consider_stop_edge_reading(): considering layer_hint->package_window 995 Sep 20 13:47:56.792 [info] {EDGE} connection_edge_reached_eof(): conn (fd 14) reached eof. Closing. I assume it can take several seconds for the exit relay to stop sending data and the Tor client has to continue reading from the stream to keep the circuit usable. Is that correct? Is it intended behaviour for the Tor client to forget a stream id before the stream is actually closed on the remote end? Fabian

2 2

Tor-related postdoc position available
by Ian Goldberg 19 Sep '11

19 Sep '11

In case you're interested but hadn't yet heard, I've got a postdoctoral researcher position available "in the field of privacy-enhancing technologies, preferably on the topic of privacy-preserving communications systems". If you (or someone you know) is finishing up a PhD and would like to work on PETs/Tor stuff with us Waterloo folks, drop me a line (noting "Postdoctoral position" in the subject line). Details are here: http://crysp.uwaterloo.ca/prospective/postdoc/ Thanks, - Ian

1 0

Building an automatic censorship-detection system for Tor
by Karsten Loesing 17 Sep '11

17 Sep '11

In the past years we observed sudden drops in Tor usage in certain countries. Some of these events may be attributed to countries specifically wanting to block Tor, as it enables their citizens to circumvent their censorship infrastructure. Other events likely result from country-wide Internet outages that are unrelated to Tor. Two such events happened in January 2011 in Iran [0] and Egypt [1]. The key point is that we can derive from observed Tor usage when something potentially interesting is going on in a country. We should be able to build a system that keeps track of our daily user estimates per country and automatically sends out a warning whenever there are sudden changes. George Danezis wrote "An anomaly-based censorship-detection system for Tor" [2]. George's detection code [3] uses our daily user estimates [4] as input and gives a list of sudden upturns and downturns per country as output. We integrated the results of his script in the metrics website [5] to demonstrate what events the detector recognizes as possible censorship events. For example, the detector would have warned in January 2011 about the events in Iran [6] and Egypt [7], shown as red dots for downturns. However, as one can see, George's script also detects quite a few false positives. Whenever there's a red or blue dot, the script would have issued a warning for a human to check. It would be neat to reduce these false warnings while still catching the really suspicious events. Want to help us make our censorship-detection system better? Any suggestion to improve George's algorithm or to come up with an alternative approach to detect possible censorship events in our data would be much appreciated! Let us know if we can help you get started. [0] https://metrics.torproject.org/users.html?graph=direct-users&start=2011-01-… [1] https://metrics.torproject.org/users.html?graph=direct-users&start=2011-01-… [2] https://metrics.torproject.org/papers/detector-2011-08-11.pdf [3] https://gitweb.torproject.org/metrics-tasks.git/tree/HEAD:/task-2718 [4] https://metrics.torproject.org/csv/direct-users.csv [5] https://metrics.torproject.org/users.html#censorship-events [6] https://metrics.torproject.org/users.html?graph=direct-users&start=2011-01-… [7] https://metrics.torproject.org/users.html?graph=direct-users&start=2011-01-…

3 2

Run Tor relay in background on OS X
by Doug Ransom 03 Sep '11

03 Sep '11

Hi, I was thinking of tweaking TOR and/or Vidalia so users can easily (i.e. w/o being a skilled unix sysadmin) to configure TOR to run at boot. Any thoughts or concerns before I poke at the source code? In the past I have had some success running TOR at boot using Launchd, but its hard and doesnt play nice with Vidalia. Doug Ransom doug.ransom(a)alumni.uvic.ca

1 0

Research problem: better guard rotation parameters
by Roger Dingledine 30 Aug '11

30 Aug '11

The next in my series of research blog posts is up: https://blog.torproject.org/blog/research-problem-better-guard-rotation-par… "What algorithm should we use to assign Guard flags such that a) we assign the flag to as many relays as possible, yet b) we minimize the chance that Alice will use the adversary's node as a guard?" --Roger

1 0

Exit Enclaving and the future of?
by Jacob Appelbaum 29 Aug '11

29 Aug '11

Hi, I'll try to sum up Exit Enclaving in no certain terms and hope that Nick or someone else will chime in to correct my assumptions. This should probably be formalized and put into the path-spec at some point. I was surprised to not see it in there to begin with but I probably just missed it. Anyway, without further delay... When Tor builds a circuit it does so with certain constraints in mind - most of these are described in the path-spec. Exit Enclaving is a set of client circuit building constraints that all go together. When a user wishes to connect to a given IP address, Tor will check this IP against all of the Tor nodes in the Tor consensus. If the IP address in question is a Tor node in the consensus, the Tor client will check the selected Tor node's exit policy. If the Tor node's exit policy allows connections to *itself* - that is the IP address of Tor node - we check that the requested port is allowed by that policy. If we find that this set of constraints is matched, we build a *four* hop circuit to the Tor node that has the same IP as our request. The Tor node that matches is the fourth hop and we force exiting to the service offered by that node. The user then exits from the Tor node that met the constraints and they're connected to the service offered by that Tor node. As a result, client security is greatly improved by using Tor as the full path to the services offered on that Tor node. Obviously, with a bit of firewall trickery, it would be possible to offer the services on another physical host but the general point still stands - the service on a given IP address may only be enclaved by an IP address that is a confirmed Tor relay. I think Exit Enclaving is confusing for the uninitiated. It is documented but not in the standard Tor ways and it appears to be one of the lesser understood things in Tor land. Here's the official documentation as far as I've found it : https://trac.torproject.org/projects/tor/wiki/doc/ExitEnclave Here's the important bits from that page: SocksPort 9050 # what port to open for local application connections SocksListenAddress 127.0.0.1 # accept connections only from localhost ORPort 9001 Nickname archivetpo ExitPolicyRejectPrivate 0 ExitPolicy accept 38.229.70.19:443 ExitPolicy reject *:* There are a few references to the term (Exit) Enclave in the torspec.git repo but none of them actually define how it works with absolute authority. At best we've described how to try to become one without actually explaining the essence concretely in a specification. I think we should add a paragraph to the man page as well as the torspec. I'd be happy to write it once we actually hammer out the current and pas client behaviour. There is a problem with the current Exit Enclaving approach and if anything, it's not the worst one to have. If the user attempts to connect with a name, we are unable to try to satisfy the constraints that require an IP address; so we just skip Enclaving entirely for that connection. After the first sucessful connection or the first time Tor resolves the name, we're able to take the above steps in our attempt to opportunistically enclave. Before that - the Tor client only knows the name and thus the IP address is a mystery. Generally this results in the first connection exiting via any other node that allows exiting to the target host. I think this is perhaps an anonymity concern as it shows that the Tor client has likely not connected to the host in question - an evil Exit might take note of this and watch for correlated streams over time, etc. Here's an example of a semi-popular website documenting their enclaving experience: http://www.gabrielweinberg.com/blog/2010/08/duckduckgo-now-operates-a-tor-e… Recently the CCC jabber server became an exit enclave and a hidden service, similar to the DuckDuckGo setup: https://twitter.com/#!/jabbercccde/status/107850926638895104 https://twitter.com/#!/jabbercccde/status/107850540842627072 As I stated previously, I think that the use of Exit Enclaves greatly improves client security. It reduces the chances of a network sniffer getting lucky, it helps to mitigate the severity of services getting crypto stuff wrong, etc. I think it would be nice to make this easier to set-up and configure for server administrators. I'd also like to make this more flexible for Tor clients and if possible, find some methods for making Tor clients automatically enclave on the first connection. There are a few ways that we might see Exit Enclaving happen on the first connection. It is possible to make the first connection enclave if the client is using the TorDNSPort; Tor will have resolved and cached the names used by all clients, connections by names should then Enclave and connections by IP will Enclave as well. Alternatively, having all connections to Tor happen by IP address only would force all clients to Enclave on first connection. I think this is probably dangerous in all cases except a Transparent Tor network. Another possible hack is to set MapAddress for the hosts that matter to you - this doesn't scale very well and it's confusing for most people; it isn't dynamic and it seems that it will likely desynchronise over time. I'd like to advocate for a simple set of options to make this stuff easier to use and more likely to be used by a server admin. Here's a bug where I suggest an option OfferExitEnclave that is either a bool or a port list: https://trac.torproject.org/projects/tor/ticket/800 My thought was that a service provider who wants to offer enhanced service to Tor users could set a single flag and it would create a Tor Exit node that only exits to itself; I imagine that it might make sense to change the advertised bandwidth. It might even be a good idea to set a reasonable bandwidth cap of sorts but I think this is probably not great until we can automatically guess intelligently. I imagine that flipping the hypothetical OfferExitEnclave switch would actually be short hand for the following: ORPort auto Nickname exitenclave MaxAdvertisedBandwidth 20KB ExitPolicyRejectPrivate 0 ExitPolicy accept ORListenConfirmedPublicAddress:* ExitPolicy reject *:* Thus when we want to help someone enclave their entire host - we tell them to flip a single flag like so: OfferExitEnclave 1 If they want to enclave a specific service on their host - we tell them to flip the same flag like so: OfferExitEnclave 1 ExitEnclavePorts 5222 I'm not sold on that set of options but I think offering at least the OfferExitEnclave option as a bool would result in a lot more clarity for a server admin who wants to enhance their services for use with Tor. I think that generally, the nice part about Exit Enclaving is that it works as well as the rest of Tor - it does not really rely on external dependencies at all - no need for DNS or DNSSEC stuff, no need for the authorities to do any extra work on a per node basis, the client can use a different exit if they like, etc. On the client side, I think that would could make some improvements that aren't merely cosmetic but when enabled would improve client security. As I've already stated, Transparent Tor networks with TorDNSPort do this automatically by the nature of how they function. Other than the Torouter and probably TAILS, I'm not sure of other projects that takes advantage of this option. I'm not even certain that it will work in the long term for Torouter because of SRV records and jabber clients. Generally the client situation as it stands today lacks a general switch to force attempts at Exit Enclaving by name. Such an option would force a full round trip. Certainly we lack a general manner that attempts to Exit Enclave for all hosts and I'd like to see that change. I think it would be nice to have a few options and I'm far from sold on any of them. I'll lay them out as if they were already implemented. LearnExitEnclaveNames 0|1 This option could learn what possible names are frequently used and opportunistically resolve them, perhaps even caching some meta-data about exit enclaves that we've used, if it was stable, etc - this is could be something like a mash up TrackHostExits, LongLivedPorts, MapAddress, and something that learns overtime the hosts you use regularly. I think it would need some work to be done in a privacy preserving manner, probably with something like scrypt, if it needed to be cached on disk. This would solve the problem of a host being a known Exit Enclave after the first resovle and then later expiring from Tor's internal DNS cache. I think this is a common problem for IM connections and simply marking that name as something worth the round trip would be a huge gain, even if only for a single Tor run where the results are never cached on disk. My Tor often runs for days at a time and I think that the DNS cache internally expires before my Tor client exits. I'm pretty sure that means that it's up to my IM client or other software to cache the IP or we're back to square zero. AttemptExitEnclaving 0|1 This option could simply force the full round trip for all connections. Simple enough but likely a major performance hit. The default would be zero and keep things as they are today. AttemptExitEnclavingPorts [port list] This option could attempt Enclaving for any connections to any host if the connection is to one of the listed ports. AlwaysAttemptEnclaveNames [list of names] This option could take a list of names where we want to force a full round trip and that we'd like to enclave. Perhaps it would even fail to work if the Enclaving would fail and perhaps it could fail in a helpful manner. I imagine that some people might like this for customised browser bundles or if they're a power user who knows what they want, etc. I know that Nick had some suggestions - perhaps adding known Exit Enclaving names into the consensus or into descriptors or something that the directory authorities handle. I'm not sure that I fully understand his suggestions and I look forward to his reply to this email. :) All the best, Jake

1 0

lround() missing in MSVC
by Gisle Vanem 24 Aug '11

24 Aug '11

lround() is missing in MS Visual-C's <math.h>. Not available anywhere. Here is an easy patch: --- Git-latest\src\common\util.c Sun Aug 14 13:48:49 2011 +++ src\common\util.c Tue Aug 23 21:15:25 2011 @@ -335,7 +335,11 @@ long tor_lround(double d) { +#ifdef _MSC_VER + return (long)(d > 0 ? d + 0.5 : ceil(d - 0.5)); +#else return lround(d); +#endif } /** Returns floor(log2(u64)). If u64 is 0, (incorrectly) returns 0. */ ---------------- --gv

2 1

Tor2web 2.0 is live!
by Arturo Filastò 20 Aug '11

20 Aug '11

Hi all, We are glad to announce the release of the new tor2web software. For those of you who are not aware of what tor2web is let us give you a brief description. The goal of tor2web is that of promoting the use of Tor Hidden Services (https://www.torproject.org/docs/hidden-services.html.en) Hidden Services allow people to run TCP based services without disclosing the identity/location of their server. In the specific they allow people to anonymously publish content to the web. Also, since you are being reached trough the Tor network, you are not required to have a static ip address or purchase a domain. This lowers the entry barrier to content publishing and protect the content publisher from retaliation and Denial of Service attacks. The problem though is that Hidden Services are usually only accessible by installing a Tor client (https://www.torproject.org/projects/torbrowser.html.en) Tor2web creates a transport, by acting as a web proxy, between the internet and the Tor network. This means that anonymous publishers are able to reach a much wider audience. The user visiting a website though tor2web is always advised to install a Tor client as by doing so he will protect his identity and leverage Hidden Services end-to-end encryption. This version of tor2web (called tor2web 2.0) is based on glype PHP web proxy (http://www.glype.com) and it is by no means the definitive solution. We are currently working on a new design that will be able to withstand other "attacks" that are currently possible. What we have implemented is: * A clear disclaimer warning the user that the content is not being served directly from the server, but it comes from the Tor network * Contact forms for abuse complaints and to report broken websites * Transparent rewriting of URLs into the tor2web form (i.e. so4rmjdiwmqjosxz.onion become so4rmjdiwmqjosxz.tor2web.org) * Blocklists to allow a tor2web node maintainer to block particular websites, the blocklists are stored in md5 format so the node maintainer does not need to store potentially illegal site lists. At this current stage we would like the community to stand-up and help us by: * Finding security and functional bugs in the existing implementation * Volounteering to run new tor2web servers: In this first stage we are looking for reliable systems, run or endorsed by trustworthy organizations involved in anonymity and privacy research and development. For the new release the goals that we wish to further pursue are: * Distribute responsibility across multiple actors * Minimize the probability of takedown of a tor2web node If you want further information on the tor2web project visit: Wiki for new developments: http://wiki.tor2web.org/ Tor2web original website: http://www.tor2web.org Github: https://github.com/globaleaks/tor2web-2.0 Mailing List: tor2web-talk(a)lists.tor2web.org on http://bit.ly/pxFwNS . IRC: irc.oftc.net #tor2web Have a nice day, Some Random GlobaLeaks Contributors Please spread across the anonimity communities and mailing lists

1 0

Blocking-Test: GSoC Penultimate Status Report
by Brandon Wiley 12 Aug '11

12 Aug '11

Scoring and reporting for detectors and encoders is pretty much done. The graphs aren't quite ready yet, for aesthetic reasons, but I have some nice tables to report: Length detector: 16% accuracy Timing detector: 89% accuracy Entropy detector: 94% accuracy SSL was correctly identified 25% of the time, 70% of the time other protocols were misidentified as being SSL, and 5% of the time SSL was misidentified as another protocol. obfsproxy was correctly identified 55% of the time, 10% of the time other protocols were misidentified as being obfsproxy, and 35% of the time obfsproxy was misidentified as another protocol. Dust was correctly identified 48% of the time, 4% of the time other protocols were misidentified as being Dust, and 48% of the time Dust was misidentified as another protocol. obfsproxy is distinguishable from SSL 96% of the time. obfsproxy is distinguishable from Dust 98% of the time. Dust is distinguishable from SSL 56% of the time. I'm sure these numbers are confusing as several different sorts of things are being measured, all with similar numbers. It is probably quite unclear how all of these percentages add up. I think this is where the graphs will help. In particular I think it's hard to visualize accuracy when there are both false positives and false negatives to take into account. I think the most interesting result here is the entropy detector. It's the simplest and also the most effective. Not only that, but the entropy detector only looks at the entropy of the first packet, so it's inexpensive. The original reason that I implemented this detector was that there was an argument against Dust that it could be trivially filtered by setting an entropy threshold above which all traffic is filtered. Surprisingly, Dust has lower entropy than SSL, so this attack will not work to specifically target Dust. This is unexpected because Dust uses totally random bytes, whereas the SSL handshake does not. This is a result of a general issue with how Shannon entropy is defined. Shannon entropy is normally defined across a large statistical sampling, in which case all three protocols tested will converge to maximum since they are all encrypted and therefore apparently random. However, the attacker does not in this case get a large statistical sample. Since they don't know a priori which connections are Dust connections, they only get however many packets are in each trace to use as samples. The current version of Dust that I'm testing has most of the advanced obfuscation stripped out as I haven't had time to add it back in after completely reimplementing the protocol to use TCP instead of UDP and all of the modified assumptions that come with that change. So this version of Dust is basically just the ntor protocol with no packet length or timing hiding in use. The first packet is therefore 32 random bytes consisting of the curve25519 ephemeral ECDH key, as compared to the 1k first packet of SSL. This is the reason for the low entropy calculation, because given only 32 bytes to sample almost all possible bytes are going to have a probability of 0 or 1. There is an upper bound on entropy when sample sizes are small. Achieving maximum first-order entropy here would require at least 512 bytes so that each value 0 to 255 could occur exactly twice. There are of course many ways to measure entropy and you could say that I'm just doing it wrong. Some alternative measurements have already been suggested that I might implement as well. I am not suggesting that Dust is in any way immune to entropy-based detection. In fact, Dust is currently detected very well by the current entropy detector (it passed 100% of the packet length and timing tests, so all detection of Dust was done by the entropy detector) precisely because it has strangely low entropy because of it's small first packets. I bring this up only as an interesting example of how intuition can fail when trying to use Shannon entropy to measure individual messages instead of channels. As far as the state of the project goes, I think the project can be considered done. Looking at the project documentation<http://stepthreeprivacy.org/documentation>, everything didn't work out exactly as originally planned, I think it all worked out for the best and the project is where I wanted it to be by the completion of Summer of Code. I have generation of HTTP and HTTPS traffic, both over Tor and plain. I have two encoders: obfs2 and Dust. I have three detectors: length, timing, and entropy. The string detector didn't work out, but the entropy detector worked out better than planned, so on balance I think it was a win. I didn't implement all of the detector modes because upon further reflection it doesn't really make sense to just try all of these different modes. You want the mode that works best. So for packet lengths and timing that is full conversations and for entropy that's the first packet (could be first N packets, but I tried N=1 and it worked great). Random sampling of packets just seems like a way to limit your success at this point when non-random sampling of just the first packet seems to be so effective. All of the utilities have been written, and more. I have the specified utilities for separating the pcap files into streams, and extracting the strings, lengths, and timings. Additionally, I have some utilities for extracting the entropy of streams, tagging the streams with what protocol they are using (by port), and extracting dictionary and corpus models for latent semantic analysis. I also have some utilities for graphing distributions of properties of different protocols which I hope to finish up next week during the wrap-up period. Looking to the future, I have changed my goals somewhat from what I had in mind at the beginning of the project. After having attended the TorDev meetup in Waterloo and the PETS conference, I am much more interested in integrating my work with the Tor project instead of just testing the various protocols that have been proposed in order to see how my own protocol stacks up against the competition. As part of this transition, I have rewritten Dust from scratch, both in terms of implementation and in terms of the protocol, in order to be better suited for use as a pluggable transport for Tor. My goal for Dust is to have it shipped with both Tor clients and bridges so that it can be used in the field to contact bridges despite DPI filtering of Tor connections. My goal now for the blocking-test project is to focus on blocking resistance for Tor. So instead of adding all of the protocols under the sun, I'm going to concentrate on protocols that have been implemented or are under consideration to become pluggable transports. Additionally, the next protocol I'm going to add after GSoC is over is just plain Tor. There is at least one bug filed about a suspicion that Tor can currently be fingerprinted based on some packet characteristics and I'd like to be able to close that bug because we now have the capability to easily generate the necessary information. Finally, I would like to offer some insight into what I think is the future of blocking-resistant transports now that I have done some work trying to break them. Fundamentally, the only thing an attacker can do is limit the bitrate of the connection. Given any sort of channel, we can encode arbitrary information over that channel. However, the smaller the channel the slower the bitrate. The goal of encodings should be to maximize the bitrate given the constraints of the censor. It's easy to develop very slow encodings such as natural language encodings over HTTP. However, in order to maximize the throughput you need to have a good definition of the attack model. All encoding for blocking-resistant purposes lowers the efficiency above just transmitting the normal content (assumed it has already been compressed). Therefore all encoded conversations are going to be longer than unencoded conversations. I think this is the future of writing detectors because it's a fundamental constraint on encoding. I think this should even be able to defeat something like Telex (although let's not get into the details of attacks on Telex specifically, I'm talking about a general idea here). Given a (static, for the sake of argument simplicity) website, I can download every page on that website. Then I can compare the length of intercepted downloads and detect when they don't match up. For dynamic websites you can do the same thing with a statistical model. I think, therefore, that the future of blocking-resisting protocols is to encode single logical connections over an ensemble of multiple actual connections. Ideally these connections would mimic normal traffic in terms of number of connections, duration, directional flow rates, etc.. It's something to think about anyway. It could be an interesting problem.

1 0

Instructions for building the Vidalia-bundle?
by Steve Snyder 09 Aug '11

09 Aug '11

Is there documentation anywhere on how to build the Vidalia-bundle for Windows? If so, where can I find it? Thanks.

3 3

GSoC Update
by Brandon Wiley 05 Aug '11

05 Aug '11

With the TorDev meetup and everything it's been a while since I sent out an update on the state of the project, although I think we more or less caught up on the status at the meetup. The bulk of the implementation work had already been completed, so what I've been working on since then is just cleaning up the code and rewriting some parts. In particular this week I rewrote the detectors to be mostly python. The core Bayesian model is still in BUGS/JAGS and there is still R code to interface with that. However, the output of the models after training is now converted to a CSV file and the actually detection code is a python program which reads the CSV file with the trained model's prediction data and the compares it to the data of a stream to be classified. This means that you only need R for training the models. If we can put together a canonical model for each protocol then you can use it to classify new traffic just using python. I think this is a win because R was the bulkiest dependency. It also segments the process more nicely in that there can be some people gathering traces, other people building models, and then other people running detectors against new traces. In terms of code cleanup, I've been adding comments and refactoring large files (in particular pavement.py) to be more readable. I also have the scoring tasks implemented so that, given the output of the detectors, the various detectors and encoders are scored based on their number of correct guesses, false positives, and false negatives. The only functionality left to implement is some sort of reporting, probably in the form of graphs of the scores so that detectors and encoders can be compared. The rest of the work is just going to be refining everything and getting both the workflow and the code structure to be smooth. Also, I've stopped working on the string detector because I realized that it's irrelevant for the two encoders I actually have support for right now: obfs2 and Dust. They both already use totally randomized packet contents and so will not be vulnerable to this kind of detector. Other encodings will be vulnerable, but the string detector can wait until we support these encodings. So instead I've implemented an entropy detector, which should work very well against both obfs2 and the current implementation of Dust. The entropy detector is actually the easiest model so far as the entropy of a trace is just a single number, so that's convenient.

1 0

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