- tor-dev - lists.torproject.org

سلام برنامه تور فارسی برای ایران
by Mohammad Mo 01 Oct '11

01 Oct '11

سلام برنامه تور فارسی برای ایران وسازگار با سرعت کم اینترنت داخلی می خاهم متشکرم mohammad_20101389(a)yahoo.com

2 2

(no subject)
by Mohammad Mo 30 Sep '11

30 Sep '11

1 0

Future direction for torperf
by Thomas S. Benjamin 30 Sep '11

30 Sep '11

Dear all, I am working on a re-design of torperf that will use a central python script to automate initiation and control of torperf experiments. I have a very rough draft that provides the most basic level of functionality in tomb/torperf.git branch 3280, and have ticket #3280 as wanting review. The code needs substantial improvement, but I would love feedback on my general approach before I spend a lot of time on grooming this specific version. If you use torperf please consider giving me feedback on the direction in which I am heading with this. I want to make sure that I am designing something that will work for other people, rather than just for my own experiments. I have chosen not to merge into a branch of torperf.git because my working style involves lots of frequent verbose commits, which would be distracting for most people. I will roll together the many commits before merging into torperf.git -- Sincerely Yours, ---Thomas S. Benjamin

2 1

سلام برنامه تور فارسی برای ایران می خواستم
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