- tor-dev - lists.torproject.org

Looking for ways to get involved
by Leonardo Camargo 04 Dec '12

04 Dec '12

Hi, First of all, if that's not a suitable message for [tor-dev], I apologise and will promptly go for [tor-talk] instead. I'm a CS undergrad and am time-pressed to present a graduation project proposal. Getting involved with Tor is something that has been on my mind for a long time, but I only now started taking the time to actually look into it. I need to present a proposal about something specific in the next few days, though I probably can refine/redirect my objectives in the following weeks. Something that really interests me is the possible move of tor traffic from tcp to udp, in the foreseeable future. I'd like to work on something that helps moving Tor closer to the point where this architectural change can start happening. Network programming and security are two topics that interest me a lot. I need something specific of the likes of "Look into X and tell us how to best achieve Y" or "Research W looking for a, b and c" ; something that could realistically help and something that can be a proposal. I'm not expecting people to teach me anything, just to point me in the right direction so I don't waste time on something that won't be realistically useful. I'm not simply looking for anything that will fit as a graduation project, I'm actually trying to combine* several goals in one*: (a) study tor in depth, (b) help out with something realistically useful, (c) graduate. And my wish in to continue my involvement with tor after my project is done. My desire is to work on "my thing" rather than my (future) advisor's thing(whatever he's got), if I come up to him with something already thought-throught he'll be less likely to try and sway me towards something else. I'm reading up the docs. But right now something specific for me to present as proposal would help a lot. Any ideas are welcome. Thanks,

1 0

Windows binary flash proxy packages
by David Fifield 03 Dec '12

03 Dec '12

Thanks to Alexandre's work on #7283, we now have Windows .exe packages of the flash proxy client programs. http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.9-win32.zip http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.9-win32.zip.… These are in addition to the already existing packages that require you to have Python installed. http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.9.zip http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.9.zip.asc Some people might be interested in the technical details of compiling Python applications on Windows. https://gitweb.torproject.org/flashproxy.git/blob/688010d2:/doc/windows-dep… https://gitweb.torproject.org/flashproxy.git/blob/688010d2:/Makefile The next step is https://trac.torproject.org/projects/tor/ticket/7621, which is about installing these programs into a Tor Browser Bundle. Perhaps we should try to coordinate this into a combined pyobfsproxy/flash proxy bundle? David Fifield

2 1

Grailo.net is live (but very young)
by Clay Graham 02 Dec '12

02 Dec '12

Hey all, You may remember an email from me about a week ago, and I could really use some pointers. We just stealth launched an alpha version of http://grailo.net and I would love all of you to try it out and give me feedback. Its 100% open source, 100% free, and you can even fork the project yourself on github. Its goal: Create a simple to use client side, RSA public key encryption for microblogging on the internet. The reason I am reaching out to you is I am I am interested in creating a client side plugin for the TOR browser so that people can use the client side encryption safely and privately, and without fear. Since scripting is disabled in TOR, with good reason, I want a plugin that is blessed by the TOR project as open and safe for encryption. Any leads on where to get started are greatly appreciated. Clay

4 6

Damian's Status Report - November 2012
by Damian Johnson 02 Dec '12

02 Dec '12

November was a month that included eating far too much pie. There was some stem work too on the side, though delicious pumpkin pies are always how that month should be remembered. My primary focus for November was tor event handling [1], which is the last major feature we need before having parity with TorCtl. We presently support nine of the nineteen event types, including the most commonly used ones (logging, BW, CIRC, STREAM, etc). I'll be spending a good chunk of December finishing this up. Besides this I've been really thrilled at how contributors are coming out of the woodwork to help! Ravi * Ravi has volunteered to take a lead on moving stem onto tor's site. Unfortunately this is presently blocked on getting a subdomain. [2] * Provided a patch to move stem's controller exceptions to the top level namespace. [3] * Fix for the repurpose_circuit() integ test [4] and discovered an issue with the stem.process test. [5] Eoin * Submitted a great patch overhauling and expanding verification of server descriptor content. [6] * Caught a possible tor bug related to 'GETINFO orconn-status' queries when disconnected. [7] * Numerous spelling fixes [8] and caught an issue with respect to how the descriptor reader handles archives. [9] Sean * Reviewed my event parsing branch, offering feedback [10] and catching a bug where STREAM events could have a zero port. [11] * Submitted patches to add close_circuit() to the Controller [12] and a setup.py [13]. The former led to a discussion about stem's licensing and copyright for patches. * Helped resolve an issue with EXTENDCIRCUIT where we weren't taking into account when the path was optional or not. [14] Other things I did this month includes... * Preparation for the 2013 Outreach Program for Women [15], the application deadline for which is now only two days away. This mostly involved helping others add their project ideas to the volunteer page and adding one of my own. [16] * Made a landing page for stem's bug tracking [17] and linked to it from stem's site. * Revamped stem's enum documentation to be both more readable and support interlinking. [18] * Provided a code review for Karsten's pygeodate.py. [19] * Answered a handful of controller inquiries on our lists. Stem's now at a point where I don't mind suggesting it to developers. If you're scripting or writing an application around tor then please give stem a try! I'd love to get more feedback on where its rough edges are before we make an initial release. [20][21][22][23] Cheers! -Damian [1] https://trac.torproject.org/7328 [2] https://trac.torproject.org/7324 [3] https://trac.torproject.org/6357 [4] https://trac.torproject.org/7259 [5] https://trac.torproject.org/7284 [6] https://trac.torproject.org/5810 [7] https://trac.torproject.org/7558 [8] https://gitweb.torproject.org/stem.git/commitdiff/2a59741 [9] https://gitweb.torproject.org/stem.git/commitdiff/69c55ab [10] https://trac.torproject.org/7328#comment:3 [11] https://trac.torproject.org/7598 [12] https://trac.torproject.org/7566 [13] https://trac.torproject.org/7565 [14] https://trac.torproject.org/6666 [15] https://live.gnome.org/OutreachProgramForWomen [16] https://www.torproject.org/getinvolved/volunteer.html.en#stemUsability [17] https://trac.torproject.org/projects/tor/wiki/doc/stem/bugs [18] https://gitweb.torproject.org/stem.git/commitdiff/0e99a26 [19] https://trac.torproject.org/6471 [20] https://lists.torproject.org/pipermail/tor-relays/2012-November/001774.html [21] https://lists.torproject.org/pipermail/tor-talk/2012-November/026299.html [22] https://lists.torproject.org/pipermail/tor-dev/2012-November/004162.html [23] https://lists.torproject.org/pipermail/tor-dev/2012-November/004195.html

2 1

Re: [tor-dev] [tor-talk] torsocks is broken and unmaintained
by Jacob Appelbaum 02 Dec '12

02 Dec '12

Matthew Finkel: > On 11/02/2012 07:36 PM, Jacob Appelbaum wrote: >> Nick Mathewson: >>> On Fri, Nov 2, 2012 at 1:34 PM, adrelanos <adrelanos(a)riseup.net> wrote: >>>> >>>> >>>> Could you blog it please? >>> >>> >>> I'd like to see more discussion from more people here first, and see >>> whether somebody steps up to say, "Yeah, I can maintain that" here, or >>> whether somebody else who knows more than me about the issues has something >>> to say. Otherwise I don't know whether to write a "looking for maintainer" >>> post, a "who wants to fork" post, a "don't use Torsocks, use XYZZY" post, >>> or what. >>> >> >> If Robert wants someone to maintain it, I'd be happy to do so. I had >> wanted to extend it to do some various things anyway. I think it would >> be a suitable base for a bunch of things I'd like to do in the next year. >> >> All the best, >> Jake >> > > I saw this thread earlier but didn't have a chance to reply. I was > thinking about volunteering to patch it up and maintain it if no one > else wanted to take it on, also, but if you want to take the lead on it > then I'm more than happy to help you where ever possible...assuming this > is the direction that's decided upon. > Hi, I've pushed my first branch to fix the dlopen bugs: https://gitweb.torproject.org/torsocks.git/shortlog/refs/heads/dlerror It seems to fix the issues on my Ubuntu system. I could use some testing on OS X, other GNU/Linux, and *BSD systems. I've also updated the bug: http://code.google.com/p/torsocks/issues/detail?id=3 One person has found that it fixed the issue for them as well. Also - it seems that we probably should address this issue very soon: http://code.google.com/p/torsocks/issues/detail?id=37 https://trac.torproject.org/projects/tor/wiki/doc/torsocks#WorkaroundforIPv… I've taken a stab at at least blocking IPv6 connect() calls: https://gitweb.torproject.org/torsocks.git/shortlog/refs/heads/ipv6 https://gitweb.torproject.org/torsocks.git/commit/95528585c1d13b0e17e9d3538… Thoughts? All the best, Jake

4 5

OutreachProgramForWomen
by Buket akın 02 Dec '12

02 Dec '12

Hi everybody, My name is Buket Akın and I am from Turkey, Çanakkale. I am computer engineering student at Çanakkale 18 Mart University. I am going to refer " Stem Usability Improvements" project. Please can you tell me what can I do about project? Thanks very much for your kindness.

2 1

Proposal 216: Improved circuit-creation key exchange
by Nick Mathewson 01 Dec '12

01 Dec '12

Hi, all. This is just the ntor proposal draft, as circulated last year, but with a proposal number assigned to it, and a closing section about how to make Tor actually work with it. Filename: 216-ntor-handshake.txt Title: Improved circuit-creation key exchange Author: Nick Mathewson Created: 11-May-2011 Status: Open Summary: This is an attempt to translate the proposed circuit handshake from "Anonymity and one-way authentication in key-exchange protocols" by Goldberg, Stebila, and Ustaoglu, into a Tor proposal format. It assumes that proposal 200 is implemented, to provide an extended CREATE cell format that can indicate what type of handshake is in use. Notation: Let a|b be the concatenation of a with b. Let H(x,t) be a tweakable hash function of output width H_LENGTH bytes. Let t_mac, t_key, and t_verify be a set of arbitrarily-chosen tweaks for the hash function. Let EXP(a,b) be a^b in some appropriate group G where the appropriate DH parameters hold. Let's say elements of this group, when represented as byte strings, are all G_LENGTH bytes long. Let's say we are using a generator g for this group. Let a,A=KEYGEN() yield a new private-public keypair in G, where a is the secret key and A = EXP(g,a). If additional checks are needed to insure a valid keypair, they should be performed. Let PROTOID be a string designating this variant of the protocol. Let KEYID be a collision-resistant (but not necessarily preimage-resistant) hash function on members of G, of output length H_LENGTH bytes. Instantiation: Let's call this PROTOID "ntor-curve25519-sha256-1" (We might want to make this shorter if it turns out to save us a block of hashing somewhere.) Set H(x,t) == HMAC_SHA256 with message x and key t. So H_LENGTH == 32. Set t_mac == PROTOID | ":mac" t_key == PROTOID | ":key" t_verify == PROTOID | ":verify" Set EXP(a,b) == curve25519(.,b,a), and g == 9 . Let KEYGEN() do the appropriate manipulations when generating the secret key (clearing the low bits, twiddling the high bits). Set KEYID(B) == B. (We don't need to use a hash function here, since our keys are already very short. It is trivially collision-resistant, since KEYID(A)==KEYID(B) iff A==B.) Protocol: Take a router with identity key digest ID. As setup, the router generates a secret key b, and a public onion key B with b, B = KEYGEN(). The router publishes B in its server descriptor. To send a create cell, the client generates a keypair x,X = KEYGEN(), and sends a CREATE cell with contents: NODEID: ID -- H_LENGTH bytes KEYID: KEYID(B) -- H_LENGTH bytes CLIENT_PK: X -- G_LENGTH bytes The server generates a keypair of y,Y = KEYGEN(), and computes secret_input = EXP(X,y) | EXP(X,b) | ID | B | X | Y | PROTOID KEY_SEED = H(secret_input, t_key) verify = H(secret_input, t_verify) auth_input = verify | ID | B | Y | X | PROTOID | "Server" The server sends a CREATED cell containing: SERVER_PK: Y -- G_LENGTH bytes AUTH: H(auth_input, t_mac) -- H_LENGTH byets The client then checks Y is in G^* [see NOTE below], and computes secret_input = EXP(Y,x) | EXP(B,x) | ID | B | X | Y | PROTOID KEY_SEED = H(secret_input, t_key) verify = H(secret_input, t_verify) auth_input = verify | ID | B | Y | X | PROTOID | "Server" The client verifies that AUTH == H(auth_input, t_mac). [NOTE: It may be adequate to check that EXP(Y,x) is not the point at infinity. See tor-dev thread.] Both parties now have a shared value for KEY_SEED. They expand this into the keys needed for the Tor relay protocol. Key expansion: Currently, the key expansion formula used by Tor here is K = SHA(K0 | [00]) | SHA(K0 | [01]) | SHA(K0 | [02]) | ... where K0==g^xy, and K is divvied up into Df, Db, Kf, and Kb portions. Instead, let's have it be K = K_0 | K_1 | K_2 | K_3 | ... Where K_0 = H(m_expand | INT8(i) , KEY_SEED ) and K_(i+1) = H(K_i | m_expand | INT8(i) , KEY_SEED ) and m_expend is an arbitrarily chosen value, and INT8(i) is a octet with the value "i". Ian says this is due to a construction from Krawczyk at http://eprint.iacr.org/2010/264 . Let m_expand be PROTOID | ":key_expand" Performance notes: In Tor's current circuit creation handshake, the client does: One RSA public-key encryption A full DH handshake in Z_p A short AES encryption Five SHA1s for key expansion And the server does: One RSA private-key decryption A full DH handshake in Z_p A short AES decryption Five SHA1s for key expansion While in the revised handshake, the client does: A full DH handshake A public-half of a DH handshake 3 H operations for the handshake 3 H operations for the key expansion and the server does: A full DH handshake A private-half of a DH handshake 3 H operations for the handshake 3 H operations for the key expansion Integrating with the rest of Tor: Add a new optional entry to router descriptors and microdescriptors: "onion-key-ntor" SP Base64Key NL where Base64Key is a base-64 encoded 32-byte value, with padding omitted. Add a new consensus method to tell servers to copy "onion-key-ntor" entries to from router descriptors to microdescriptors. Add a "UseNTorHandshake" configuration option and a corresponding consensus parameter to control whether clients use the ntor handshake. If the configuration option is "auto", clients should obey the consensus parameter. Have the configuration default be "auto" and the consensus value initially be "0". Reserve the handshake type [00 01] for this handshake in CREATE2 and EXTEND2 cells.

3 5

Parallel relaycrypt data structures for review
by Andrea Shepard 01 Dec '12

01 Dec '12

Please review first draft proposed parallel relaycrypt structures in my parallel_relay_crypt branch. -- Andrea Shepard <andrea(a)torproject.org> PGP fingerprint: 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5

3 3

questions about extending circuit
by succer110＠tiscali.it 30 Nov '12

30 Nov '12

Hi all, I need to create specific circuit, specifying the exit route. I've already found http://www.thesprawl.org/research/tor-control-protocol/ but this explain how to create circuit with nickames.Suddenly, nickname are not univoque and i think tor have problem creating circuit when the nickname of the exitroute is "Unnamed".Sometimes the creation of a new circuit fails:extendcircuit 0 hackerspaceseoul552 No such router "hackerspaceseoul"extendcircuit 0 HackerSpaceSeoul552 No such router "HackerSpaceSeoul"extendcircuit 0 HackerspaceSeoul552 No such router "HackerspaceSeoul"Even if https://atlas.torproject.org/#search/hack told me they are online. And sometimes this appends even with TorCtl.py DEBUG[Thu Nov 29 23:40:45 2012]:Extending circuit[!!!] Error creating circuit: 552 No such router "Communist" How can i fix? Thank you :) Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/

2 1

Tor Safe RSA Plugin
by Clay Graham 29 Nov '12

29 Nov '12

I am creating a twitter clone with RSA public key encryption and making it feely available. tweet from my feed: ================= new: http://grailo.org <http://t.co/M1Pbgkdn> twitter clone meets public key encryption github: http://bit.ly/UmUsxm <http://t.co/SCVAvVa4> pic: http://bit.ly/UmUdCn <http://t.co/hchO3QWL> https://twitter.com/claytantor Looking to create a Tor Browser plugin that can do client side decryption. Happy to use javascript, c or java. Clay

1 0

Compiling tor against OpenSSL_1_0_2-stable
by Christian Kujau 29 Nov '12

29 Nov '12

Hi, while trying to compile the latest git-checkout against openssl-1.0.2, I've come across the following issues: ---- make[1]: Entering directory `/usr/local/src/tor-git' CC src/common/tortls.o cc1: warnings being treated as errors In file included from /opt/openssl/include/openssl/ssl.h:1382, from src/common/tortls.c:36: /opt/openssl/include/openssl/srtp.h:138: error: redundant redeclaration of ‘SSL_get_selected_srtp_profile’ /opt/openssl/include/openssl/srtp.h:135: note: previous declaration of ‘SSL_get_selected_srtp_profile’ was here make[1]: *** [src/common/tortls.o] Error 1 make[1]: Leaving directory `/usr/local/src/tor-git' make: *** [all] Error 2 ---- There is an open ticket[0] in the openssl bugtracker for this. While the proper solution is to fix openssl/include/openssl/srtp.h, I wanted to compile without -Werror. However, when adding CFLAGS="-Wno-error" during ./configure, -Werror is still added to the ./Makefile and overriding -Wno-error. When adding CFLAGS="-Wno-error" during "make" all the other CFLAGS are gone too. Thus I ended up removing -Werror from the Makefile and tortls.o compiled. While this is really an issue with openssl, I wanted to have this documented, just in case anybody else tries the same. If someone knows of a better workaround (i.e. compiling just tortls.c with -Wno-error and everything else with -Werror), please share! :-) A bit later, compilation stops again: ---- CCLD src/or/tor src/common/libor-crypto.a(aes.o): In function `aes_crypt': aes.c:(.text+0x860): undefined reference to `CRYPTO_ctr128_encrypt' collect2: ld returned 1 exit status make[1]: *** [src/or/tor] Error 1 make[1]: Leaving directory `/usr/local/src/tor-git' make: *** [all] Error 2 ---- Hm, this leaves me puzzled for now. CRYPTO_ctr128_encrypt is still included in openssl-1.0.2 and src/common/aes.o seems to be built with this function included as well, not sure why src/common/libor-crypto.a complains now: ---- $ grep -r CRYPTO_ctr128_encrypt /opt/openssl/ /opt/openssl/include/openssl/modes.h:void CRYPTO_ctr128_encrypt(const unsigned char *in, unsigned char *out, /opt/openssl/include/openssl/modes.h:void CRYPTO_ctr128_encrypt_ctr32(const unsigned char *in, unsigned char *out, Binary file /opt/openssl/bin/openssl matches Binary file /opt/openssl/lib/libcrypto.a matches $ grep -r CRYPTO_ctr128_encrypt . ./src/common/aes.c: CRYPTO_ctr128_encrypt((const unsigned char *)input, Binary file ./src/common/aes.o matches Binary file ./src/common/libor-crypto.a matches ---- Why do I (try to) build against openssl-1.0.2? I'm on Debian/stable which still ships openssl-0.9.8o and I wanted to get rid of this "use a more recent OpenSSL" message during startup :-) Otherwise, today's git-checkout of tor runs just fine when built against openssl-0.9.8 (on powerpc) - yay! Christian. [0] http://rt.openssl.org/Ticket/Display.html?id=2724 -- BOFH excuse #330: quantum decoherence

2 2

More TBB usability challenges
by Andrew Lewman 28 Nov '12

28 Nov '12

I was asked to meet with some people doing work in dangerous areas of Latin America. In general, these people can get around and work with Microsoft Windows competently. They are all fluent in English, Spanish, and various dialects found in Latin American countries. Most of them had Spanish-language versions of Windows 7 on their laptops. # Getting TBB During the discussion, an informal usability study happened. I thought having a discussion about this may be better than simply opening a trac ticket. Here's roughly the scenario. I asked people to download Tor Browser from our website. All found Tor's website via Bing. Interestingly, some searched for "tor", others for "tor browser", and one for "tor project". They were all using Internet Explorer and Bing because that's the default for Windows 7. Thankfully, our website is the top result for all three queries at Bing. They all found the big purple "Download Tor" button on the index page. Issue #1: Running TBB from the website. When clicking the orange "Download Tor Browser Bundle" button, IE prompts them to "Run", "Save", or "Cancel". All of them chose "Run". Issue #1A: When choosing "Run", a prompt appears, "The publisher of tor-browser-2.2.39-5_en-US.exe couldn't be verified. Are you sure you want to run the program?". All of them hit "Yes" and ignored the warning. Issue #1B: When the download completed, they were prompted with the 7zip self-extractor giving them a path similar to this: "C:\Users\tor\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\T868H68M\". All of them pushed the "Extract" button and let 7zip extract TBB into that temporary directory. A few of them went to the Downloads folder to try to find TBB. However, it's not there because it's extracted into a temporary folder. This folder is not reachable by the user through File Explorer. Issue #2: Downloading TBB. After some Q&A about what happened, I asked them to "Save" rather than "Run". TBB then downloads. The user is prompted with a warning box stating, "The publisher of tor-browser-2.2.39-5_en-US.exe couldn't be verified." And the user is left to choose between "Run" and "View downloads". When clicking "Run" the user is prompted with the 7-zip self-extractor prompt and "C:\Users\tor\Downloads\" is the default path. All of them hit the "Extract" button. None of them were sure what just happened nor why TBB needs to be extracted. Issue #2A: The self-extract completes and the user is left looking at their IE window with the TBB download page. Three of them went to their Downloads folder to find Tor. The other few waited for something to happen. When I asked the waiting few why they were waiting, they said because they "ran TBB" and expected the extraction to automatically start TBB for them. Issue #3: In the Downloads folder there are two things called "tor browser", one is an application the other is a file folder. See https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11… for an example. Most of the people had hundreds of files in the Download folder, so it wasn't as clear as this example screenshot. Some people wanted to run the application, because in their mind, you run an application. When asked to go into the Tor Browser folder, they all found "Start Tor Browser" and ran it (some double-left click, some right click and choose "Open"). See https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11… for what it looks like by default. Issue #4: Once TBB was started, the users would alt-tab between applications or choose various apps in their task bar at the bottom of the screen. They kept clicking the onion icon because they thought it was TBB, when it brings up the Vidalia control panel. This is what it looks like, https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11… Issue #5: No one knew what "Startpage" was nor why it was in the top bar. Just like IE, they all wanted to search from the awesome bar by default. This does work, and they can search via startpage.com via the awesome bar. From here on out, the normal TBB issues apply, as demonstrated by Greg's HotPETS paper, https://people.torproject.org/~andrew/hotpets12-1-usability.pdf # Feedback I asked how we can improve this entire process. The consensus is that TBB needs to be a single application people can just run and get the browser going. The extraction process was confusing and was sometimes called an installation process. They felt that "running" it from the tor download site was fine, so long as everything just worked and a browser window popped up. They also felt that the Vidalia control panel was unnecessary. It just confused them. The only thing they felt was valuable was the Network Map. A caveat is that we were on a US network which didn't censor. The Message Log and bridge/obfsproxy functionality wasn't needed in this case. I suspect it will be when they try this in Latin America. -- Andrew http://tpo.is/contact pgp 0x6B4D6475

1 0

Proposal: Tor Extended ORPort Authentication
by George Kadianakis 28 Nov '12

28 Nov '12

Greetings, I'm attaching a proposal for adding authentication to the Extended ORPort. The Extended ORPort is a yet unimplemented feature, that allows pluggable transports proxies to communicate with Tor; it's a prerequisite for pluggable transport statistics, rate limiting, and other cool things. Filename: XXX-ext-orport-auth.txt Title: Tor Extended ORPort Authentication Author: George Kadianakis Created: 28-11-2012 Status: Open Target: 0.2.5.x 1. Overview This proposal defines a scheme for Tor components to authenticate to each other using a shared-secret. 2. Motivation Proposal 196 introduced new ways for pluggable transport proxies to communicate with Tor. The communication happens using TCP in the same fashion that controllers speak to the ControlPort. To defend against cross-protocol attacks [0] on the transport ports, we need to define an authentication scheme that will restrict passage to unknown clients. Tor's ControlPort uses an authentication scheme called safe-cookie authentication [1]. Unfortunately, the design of the safe-cookie authentication was influenced by the protocol structure of the ControlPort and the need for backwards compatibility of the cookie-file and can't be easily reused in other use cases. 3. Goals The general goal of Extended ORPort authentication is to authenticate the client based on a shared-secret that only authorized clients should know. Furthermore, its implementation should be flexible and easy to reuse, so that it can be used as the authentication mechanism in front of future Tor helper ports (for example, in proposal 199). Finally, the protocol is able to support multiple authentication schemes and each of them has different goals. 4. Protocol Specification 4.1. Initial handshake When a client connects to the Extended ORPort, the server sends: AuthTypes [variable] EndAuthTypes [1 octet] Where, + AuthTypes are the authentication schemes that the server supports for this session. They are multiple concatenated 1-octet values that take values from 1 to 255. + EndAuthTypes is the special value 0. The client reads the list of supported authentication schemes and replies with the one he prefers to use: AuthType [1 octet] Where, + AuthType is the authentication scheme that the client wants to use for this session. A valid authentication type takes values from 1 to 255. A value of 0 means that the client did not like the authentication types offered by the server. If the client sent an AuthType of value 0, or an AuthType that the server does not support, the server MUST close the connection. 4.2. Authentication types 4.2.1 SAFE_COOKIE handshake Authentication type 1 is called SAFE_COOKIE. 4.2.1.1. Motivation and goals The SAFE_COOKIE scheme is pretty-much identical to the authentication scheme that was introduced for the ControlPort in proposal 193. An additional goal of the SAFE_COOKIE authentication scheme (apart from the goals of section 2), is that it should not leak the contents of the cookie-file to untrusted parties. Specifically, the SAFE_COOKIE protocol will never leak the actual contents of the file. Instead, it uses a challenge-response protocol (similar to the HTTP digest authentication of RFC2617) to ensure that both parties know the cookie without leaking it. 4.2.1.2. Cookie-file format The format of the cookie-file is: StaticHeader [32 octets] Cookie [32 octets] Where, + StaticHeader is the following string: "! Extended ORPort Auth Cookie !\x0a" + Cookie is the shared-secret. During the SAFE_COOKIE protocol, the cookie is called CookieString. Extended ORPort clients MUST make sure that the StaticHeader is present in the cookie file, before proceeding with the authentication protocol. Details on how Tor locates the cookie file can be found in section 5 of proposal 196. Details on how transport proxies locate the cookie file can be found in pt-spec.txt. 4.2.1.3. Protocol specification A client that performs the SAFE_COOKIE handshake begins by sending: ClientNonce [32 octets] Where, + ClientNonce is 32 octets of random data. Then, the server replies with: ServerHash [32 octets] ServerNonce [32 octets] Where, + ServerHash is computed as: HMAC-SHA256(CookieString, "ExtORPort authentication server-to-client hash" | ClientNonce | ServerNonce) + ServerNonce is 32 random octets. Upon receiving that data, the client computers ServerHash herself and validates it against the ServerHash provided by the server. If the server-provided ServerHash is invalid, the client MUST terminate the connection. Otherwise the client replies with: ClientHash [32 octets] Where, + ClientHash is computed as: HMAC-SHA256(CookieString, "ExtORPort authentication client-to-server hash" | ClientNonce | ServerNonce) Upon receiving that data, the server computers ClientHash herself and validates it against the ClientHash provided by the client. Finally, the server replies with: Status [1 octet] Where, + Status is 1 if the authentication was successfull. If the authentication failed, Status is 0. 4.3. Post-authentication After completing the Extended ORPort authentication successfully, the two parties should proceed with the Extended ORPort protocol on the same TCP connection. [0]: http://archives.seul.org/or/announce/Sep-2007/msg00000.html [1]: https://gitweb.torproject.org/torspec.git/blob/79f488c32c43562522e5592f2c19…

2 2

questions about parallel Tor circuits en masse & adoption drivers
by Simon 27 Nov '12

27 Nov '12

Hello, I'm interesting in discussing the development aspects of using Tor as a massively distributed anonymous file server where blocks (e.g. 4KB) of a particular file (e.g. even several GB in size) might be redundantly distributed on very many hidden service nodes (e.g. a unique 4KB block of a file redundantly duplicated on ~ x hidden nodes from y million total hidden service nodes) and access to the file would be high through-put because very many (e.g. cable bandwidth / 4KB, e.g. 50 Mbps is 6.25 MB/s or 1600 * 4KB blocks per second) concurrent but high latency Tor circuits. Thus each Tor circuit would still be the usual high latency, but very many Tor circuits in parallel would deliver fantastic through-put. What if Tor could handle several rolling window bundles of e.g. 1,600 parallel Tor circuits which request one small block of info from 1,600 unique hidden service nodes? Does Tor parallelized, high bandwidth file sharing already exist? Does Tor already handle a massively parallelized number of Tor circuits, on the scale of thousands or tens of thousands of Tor circuits? Is many concurrent Tor circuits desirable? Who is working on it? Would using Tor as a massively distributed anonymous file server dramatically increase the number of Tor nodes (due to file sharing being more desirable than anonymity) and therefore make the entire Tor system more resilient to attack due to high growth and orders of magnitude more nodes? Is such an expansion -- on the back of a new functional focal point; i.e. not anonymity -- politically desirable for the Tor project? Thanks, Simon Experienced network programming enthusiast from Vancouver, Canada

1 0

tor exit node modules in Tor source codes
by esolve esolve 27 Nov '12

27 Nov '12

I'm doing research on Tor and I want to modify the tor exit node functions. I downloaded the source codes from this link https://gitweb.torproject.org/tor.git/tree/b13c6becc892d9716d8645f16b5d03bd… but I can't find the modules/files which are related to tor exit functions(like receive cells from previous relay router, send HTTP/TCP connection request to webserver/remote_host, buffer management) can anyone give some hints? thanks!

1 0

Re: [tor-dev] RIAA v Verizon: 404
by Christian Kujau 27 Nov '12

27 Nov '12

On Mon, 26 Nov 2012 at 17:40, leez wrote: > The lost document was actually this one: > https://www.eff.org/document/dc-circuit-opinion-granting-verizons-motion-qu… > > I've added a redirect from the broken link, so either will get you > there now. Thanks for fixing this! Christian. -- BOFH excuse #171: NOTICE: alloc: /dev/null: filesystem full

1 0

[PATCH 1/2] New option LocalOutboundBindAddress
by Andrew Cady 27 Nov '12

27 Nov '12

This works just like OutboundBindAddress, but instead of excluding connections to loopback addresses, it affects only connections to loopback addresses. The whitespace in this commit is a bit nutty, in order to put whitespace changes into a separate commit. --- doc/tor.1.txt | 11 +++++++++++ src/or/config.c | 25 ++++++++++++++++--------- src/or/connection.c | 17 ++++++++++------- src/or/or.h | 6 ++++++ 4 files changed, 43 insertions(+), 16 deletions(-) diff --git a/doc/tor.1.txt b/doc/tor.1.txt index 1e1ff1e..f25234d 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -477,6 +477,17 @@ GENERAL OPTIONS This setting will be ignored for connections to the loopback addresses (127.0.0.0/8 and ::1). +**LocalOutboundBindAddress** __IP__:: + Like OutboundBindAddress, but _only_ for connections to loopback + addresses (e.g., inbound connections to local hidden services). + This is useful to distinguish Tor traffic from local traffic in + the log files of your hidden services. + + + + The IP should be in the 127.0.0.0/8 range for maximum compatibility. + I recommend using 127.84.111.114, since 84.111.114 is the ASCII + encoding of "Tor". I also recommend adding \'127.84.111.114 tor' to + your /etc/hosts file. + **PidFile** __FILE__:: On startup, write our PID to FILE. On clean shutdown, remove FILE. diff --git a/src/or/config.c b/src/or/config.c index 206ccc8..03e07f9 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -285,6 +285,7 @@ static config_var_t option_vars_[] = { OBSOLETE("IgnoreVersion"), V(KeepalivePeriod, INTERVAL, "5 minutes"), VAR("Log", LINELIST, Logs, NULL), + V(LocalOutboundBindAddress, LINELIST, NULL), V(LogMessageDomains, BOOL, "0"), OBSOLETE("LinkPadding"), OBSOLETE("LogLevel"), @@ -5556,15 +5557,20 @@ getinfo_helper_config(control_connection_t *conn, static int parse_outbound_addresses(or_options_t *options, int validate_only, char **msg) { - const config_line_t *lines = options->OutboundBindAddress; - int found_v4 = 0, found_v6 = 0; + int i; + for (i=0; i<2; ++i) { + + tor_addr_t *out4 = i ? &options->OutboundBindAddressIPv4_ : &options->LocalOutboundBindAddressIPv4_; + tor_addr_t *out6 = i ? &options->OutboundBindAddressIPv6_ : &options->LocalOutboundBindAddressIPv6_; if (!validate_only) { - memset(&options->OutboundBindAddressIPv4_, 0, - sizeof(options->OutboundBindAddressIPv4_)); - memset(&options->OutboundBindAddressIPv6_, 0, - sizeof(options->OutboundBindAddressIPv6_)); + memset(out4, 0, sizeof(*out4)); + memset(out6, 0, sizeof(*out6)); } + + const config_line_t *lines = i ? options->OutboundBindAddress : options->LocalOutboundBindAddress; + int found_v4 = 0, found_v6 = 0; + while (lines) { tor_addr_t addr, *dst_addr = NULL; int af = tor_addr_parse(&addr, lines->value); @@ -5577,7 +5583,7 @@ parse_outbound_addresses(or_options_t *options, int validate_only, char **msg) return -1; } found_v4 = 1; - dst_addr = &options->OutboundBindAddressIPv4_; + dst_addr = out4; break; case AF_INET6: if (found_v6) { @@ -5587,7 +5593,7 @@ parse_outbound_addresses(or_options_t *options, int validate_only, char **msg) return -1; } found_v6 = 1; - dst_addr = &options->OutboundBindAddressIPv6_; + dst_addr = out6; break; default: if (msg) @@ -5599,7 +5605,8 @@ parse_outbound_addresses(or_options_t *options, int validate_only, char **msg) tor_addr_copy(dst_addr, &addr); lines = lines->next; } - return 0; + } + return 0; } /** Load one of the geoip files, <a>family</a> determining which diff --git a/src/or/connection.c b/src/or/connection.c index dbcfc41..397a2dc 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -1451,14 +1451,17 @@ connection_connect(connection_t *conn, const char *address, make_socket_reuseable(s); - if (!tor_addr_is_loopback(addr)) { + { + const int is_local = tor_addr_is_loopback(addr); const tor_addr_t *ext_addr = NULL; - if (protocol_family == AF_INET && - !tor_addr_is_null(&options->OutboundBindAddressIPv4_)) - ext_addr = &options->OutboundBindAddressIPv4_; - else if (protocol_family == AF_INET6 && - !tor_addr_is_null(&options->OutboundBindAddressIPv6_)) - ext_addr = &options->OutboundBindAddressIPv6_; + const tor_addr_t *maybe_ext_addr4 = is_local ? &options->LocalOutboundBindAddressIPv4_ : &options->OutboundBindAddressIPv4_; + const tor_addr_t *maybe_ext_addr6 = is_local ? &options->LocalOutboundBindAddressIPv6_ : &options->OutboundBindAddressIPv6_; + + if (protocol_family == AF_INET && !tor_addr_is_null(maybe_ext_addr4)) + ext_addr = maybe_ext_addr4; + else if (protocol_family == AF_INET6 && !tor_addr_is_null(maybe_ext_addr6)) + ext_addr = maybe_ext_addr6; + if (ext_addr) { struct sockaddr_storage ext_addr_sa; socklen_t ext_addr_len = 0; diff --git a/src/or/or.h b/src/or/or.h index a8645f8..a832e4f 100644 --- a/src/or/or.h +++ b/src/or/or.h @@ -3181,6 +3181,12 @@ typedef struct { tor_addr_t OutboundBindAddressIPv4_; /** IPv6 address derived from OutboundBindAddress. */ tor_addr_t OutboundBindAddressIPv6_; + /** Local address to bind outbound sockets -- for loopback connections (e.g., hidden services) */ + config_line_t *LocalOutboundBindAddress; + /** IPv4 address derived from LocalOutboundBindAddress. */ + tor_addr_t LocalOutboundBindAddressIPv4_; + /** IPv6 address derived from LocalOutboundBindAddress. */ + tor_addr_t LocalOutboundBindAddressIPv6_; /** Directory server only: which versions of * Tor should we tell users to run? */ config_line_t *RecommendedVersions; -- 1.7.10.4

1 1

RIAA v Verizon: 404
by Christian Kujau 26 Nov '12

26 Nov '12

Hi, the Tor DMCA response[0] has a link inside for the RIAA v. Verizon case: https://www.eff.org/legal/cases/RIAA_v_Verizon/opinion-20031219.pdf But this document is no longer available at this address, thus producing a 404. @EFF Webmaster, could you please fix this or provide the new address of this document? Is this perhaps the following: https://www.eff.org/sites/default/files/filenode/RIAA_v_Verizon/20030121-ri… I've cc'ed tor-dev, because the link is included in contrib/tor-exit-notice.html for the Tor exit nodes to present. Thanks, Christian. [0] https://www.torproject.org/eff/tor-dmca-response -- BOFH excuse #60: system has been recalled

2 1

Re: [tor-dev] Request for comments on notes on parallel cell crypto
by Nick Mathewson 19 Nov '12

19 Nov '12

On Sun, Nov 18, 2012 at 7:43 PM, Andrea Shepard <andrea(a)torproject.org> wrote: > I've made some notes on parallelizing cell crypto on relays which I've > attached to this mail and added to the wiki page on this [1], which I > would like comment on. Particularly, I want to resolve the following > points: > > * Should we operate on cell_t or packed_cell_t? After reading your comments, I don't feel strongly that packed_cell_t is correct. Either would probably be okay. I think I might have said "packed_cell_t" on the grounds that we already have a specialized allocator for them, whereas we don't currently heap-allocate as many cell_t as we would need for this. I might also have said "packed_cell_t" on the theory that copying data from cell_t to packed_cell_t would waste cycles, but I'm not sure that's significant here. Or maybe I was thinking of the amount of space wasted in packed_cell_t vs cell_t, and worried about the number of queued cells we're likely to have at once. For queueing the cell_ts, and where to put a next pointer: I *think* (but can't be sure) that most of our cell_t objects are currently short-lived, and most of our long-lived cell objects are currently packed_cell_t. So adding fields to cell_t wouldn't hurt much, since they don't currently represent very much of our total allocation, I think. (We should double-check that!) > * Is it acceptable for the main thread to call functions to > manipulate job-dispatching data structures that need to > acquire a lock if we can be sure everything that ever > holds the lock only does so very briefly to manipulate > those structures and will never block while holding it, > or do we need to design something that's lock-free for > the main thread? I don't think the main thread needs to be lock-free so long as it won't often block for too long. I was initially planning to have locks protect the work-queues initially, and only substitute in a lock-free work-queue implementation if it turned out to matter. (How long the lock is held by the main thread is less important for performance IIUC than whether the main thread will spend much time blocked waiting for the lock, or how much lock contention there will be.) > * The functions that currently call relay_crypt()/ > relay_crypt_one_payload() will have to be split into > two parts, one that queues a cell to be crypted and > another that handles the finished, crypted cell. > How will the worker threads cause the second part to > be called in the main thread? (NickM, there's probably > some libevent voodoo I don't know about yet for this?) So, I'd suggest the we start with a work queue each way: one queue (or set of queues) to enqueue stuff for worker threads, and one to enqueue the crypted stuff for the main cell to process it. That said, we'll need a way to alert the main thread "Hey, you have more data on your queue!" The easiest way to do that is, using Libevent 2.0 or later, to just call event_active() on a "struct event" whose callback processes the data. (This needs to require Libevent 2.0 or later, since Libevent 1.4 and earlier didn't let you do this threadsafely.) The next easiest alternative would be to construct a socketpair, have the main thread listen on the read side of it (using a read event), and have the worker thread write a byte to the socketpair whenever the queue went from "observed" . There are faster ways to do all of the above, and more ways we could optimize libevent to help with our particular case, but for now I'll suggest we ignore them: getting even one extra core to do crypto with will more than pay for all the overhead in a v1 implementation. We can find the painful points and optimize them later -- and waiting to do so will ensure we don't waste time optimizing outside of critical paths. In fact, we should probably be doing this for the rest of the design: looking to see if there are cases where even if we think we might need to get complex eventually, we can still do them simply at first. (For the case of sending work to the worker threads, a mutex/condition-var pair will do. Windows Vista added real condition variables, and there's plenty of compat code around to fake them with earlier Windowses.) I suggest that for the first implementation of this, we can just make the multithreaded crypto stuff require Libevent 2.0 or later. We'll want a compile option to turn it off for old OpenBSDs anyway. Turning multithreaded cypto off should be easy, right? Instead of "Thread1: enqueue. Thread2: unqueue, encrypt, enqueue. Thread1: unqueue, process", you just replace the first "enqueue" operation with "encrypt and process" -- perhaps making a stub relaycrypt_dispatcher_t that doesn't actually dispatch anything, but just does the crypto operation immediately. This might even be a good intermediate step while refactoring the crypto. > Once these are resolved I'll be making a branch for this and > writing the headers with proposed data structures and interfaces > for review. Cool; thank you! Another observation about your design sketch: If we implement this nicely, I think it will be possible to stress-test it and load-test the relaycrypt_dispatcher_t part of it without actually requiring the rest of Tor to be running. IOW, we could have a performance-test for this component that didn't require any actual Tor traffic to be happening, or circuits to exist. IMO that would be a pretty good idea, since it would help us optimize as needed, and it would encourage loose coupling. cheers, -- Nick

3 3

Proposal 215: Let the minimum consensus method change with time
by Nick Mathewson 19 Nov '12

19 Nov '12

Filename: 215-update-min-consensus-ver.txt Title: Let the minimum consensus method change with time Author: Nick Mathewson Created: 15 Nov 2012 Status: Open 0. Overview This proposal suggests that we drop the requirement that authorities support the very old consensus method "1", and instead move to a wider window of recognized consensus methods as Tor evolves. 1. Background and Motivation When we designed the directory voting system, we added the notion of "consensus method" so that we could smoothly upgrade the voting process over time. We also said that all authorities must support the consensus method '1', and must fall back to it if they don't support the method that the supermajority of authorities will choose. Consensus method 1 is no longer viable for the Tor network. It doesn't result in a microdescriptor consensus, and omits other fields that clients need in order to work well. Consensus methods under 12 have security issues, since they let a single authority set a consensus parameter. In the future, new consensus methods will be needed so that microdescriptor-using clients can use IPv6 exits and ECC onion-keys. Rolling back from those would degrade functionality. We need a way to change the minimum consensus method over time. 2. Design I propose that we change the minimum consensus method about once per release cycle, or once per ever other release cycle. As a rule of thumb, let the minimum consensus method in Tor series X be the highest method supported by the oldest version that "anybody reasonable" would use for running an authority. Typically, that's the stable version of the previous release series. For flexibility, it might make sense to choose a slightly older method, if falling back to that method wouldn't cause security problems. For example, while Tor 0.2.4.x is under development, authorities should really not be running anything before Tor 0.2.3.x. Tor 0.2.3.x has supported consensus method 13 since 0.2.3.21-rc, so it's okay for 0.2.4.x to require 13 as the minimum method. We even might go back to method 12, since the worst outcome of not using 13 would be some warnings in client logs. Consensus method 12 was a security improvement, so we don't want to roll back before that. 2.1. Behavior when the method used is one we don't know The spec currently says that if an authority sees that a method will be used that it doesn't support, it should act as if the consensus method will be "1". This attempt will be doomed, since the other authorities will be computing the consensus with a more recent method, and any attempt to use method "1" won't get enough signatures. Instead, let's say that authorities fall back to the most recent method that they *do* support. This isn't any likelier to reach consensus, but it is less likely to result in anybody signing something they don't like. 3. Likely outcomes If a bunch of authorities were to downgrade to a much older version, all at once, then newer authorities would not be able to sign the consensus they made. That's probably for the best: if a bunch of authorities were to suddenly start running 0.2.0.x, consensing along with them would be a poor idea. 4. Alternatives We might choose a less narrow window of allowable method, when we can do so securely. Maybe two release series, rather than one, would be a good interval to do when the consensus format isn't changing rapidly. We might want to have the behavior when we see that everybody else will be using a method we don't support be "Don't make a consensus at all." That's harder to program, though.

1 0

Free and Open Source Software internships for women
by Sathyanarayanan Gunasekaran 16 Nov '12

16 Nov '12

Free and Open Source Software (FOSS) is software that gives the user the freedom to use, copy, study, change, and improve it. FOSS contributors believe that this is the best way to develop software because it benefits society, creates a fun collaborative community around a project, and allows anyone to make innovative changes that reach many people. In an effort to get more women involved in FOSS, a number of organizations are offering Outreach Program for Women internships from January 2 to April 2, 2013. The application deadline is December 3, 2012. The applicants need to get in touch with individual projects they are interested in working on and make a small contribution ahead of the application deadline. Participants will work remotely from home, while getting guidance from an assigned mentor and collaborating within their project’s team and the rest of the FOSS community. The projects include software development, system administration, web development, user experience design, graphic design, documentation, and marketing. The stipend for the program is $5,000 (USD). Any woman available for a full time internship who has not previously participated in the Outreach Program for Women or Google Summer of Code is welcome to apply. College women from the Southern Hemisphere who will have a school summer break during most of this time are particularly encouraged to apply. Please visit https://www.torproject.org/getinvolved/volunteer.html.en#opw to learn more and apply.

1 0

Proposal 214: Allow 4-byte circuit IDs in a new link protocol
by Nick Mathewson 10 Nov '12

10 Nov '12

Filename: 214-longer-circids.txt Title: Allow 4-byte circuit IDs in a new link protocol Author: Nick Mathewson Created: 6 Nov 2012 Status: Open 0. Overview Relays are running out of circuit IDs. It's time to make the field bigger. 1. Background and Motivation Long ago, we thought that 65535 circuit IDs would be enough for anybody. It wasn't. But our cell format in link protocols is still: Cell [512 bytes] CircuitID [2 bytes] Command [1 byte] Payload [509 bytes] Variable-length cell [Length+5 bytes] CircID [4 bytes] Command [1 byte] Length [2 bytes] Payload [Length bytes] This means that a relay can run out of circuit IDs pretty easily. 2. Design I propose a new link cell format for relays that support it. It should be: Cell [514 bytes] CircuitID [4 bytes] Command [1 byte] Payload [509 bytes] Variable cell (Length+7 bytes) CircID [4 bytes] Command [1 byte] Length [2 bytes] Payload [Length bytes] We need to keep the payload size in fixed-length cells to its current value, since otherwise the relay protocol won't work. This new cell format should be used only when the link protocol is 4. (To negotiation link protocol 4, both sides need to use the "v3" handshake, and include "4" in their version cells. If version 4 or later is negotiated, this is the cell format to use.) 2.1. Better allocation of circuitID space In the current Tor design, circuit ID allocation is determined by whose RSA public key has the lower modulus. How ridiculous! Instead, I propose that when the version 4 link protocol is in use, the connection initiator use the low half of the circuit ID space, and the responder use the low half of the circuit ID space. 3. Discussion * Why 4 bytes? Because 3 would result in an odd cell size, and 8 seems like overkill. * Will this be distinguishable from the v3 protocol? Yes. Anybody who knows they're seeing the Tor protocol can probably tell by the TLS record sizes which version of the protocol is in use. Probably not a huge deal though; which approximate range of versions of Tor a client or server is running is not something we've done much to hide in the past. * Why a new link protocol and not a new cell type? Because pretty much every cell has a meaningful circuit ID. * Okay, why a new link protocol and not a new _set of_ cell types? Because it's a bad idea to mix short and long circIDs on the same channel. (That would leak which cells go with what kind of circuits ID, potentially.) * How hard is this to implement? I wasn't sure, so I coded it up. I've got a probably-buggy implementation in branch "wide_cird_ids" in my public repository. Be afraid! More testing is needed!

5 6

authentication questions on Tor controller
by jiang song 08 Nov '12

08 Nov '12

I just start to use tor controller, I notice the mannual says: pass Tor the "--CookieAuthentication 1" option when you start it. Tor will create a file in its data directory called "control_auth_cookie". All your controller needs to do is to pass the contents of this file to authenticate() when it connects to Tor. there are two kinds of Tor, one is installed and can be run by command "tor" the other is Tor Browser Bundle, 1) with command "tor", when it establishes, if I run example.py the result is "Connection refused. Is the ControlPort enabled?" I tried command: "tor --CookieAuthentication 1" to start Tor, but I can't find the so called data directory, and the running information says： Could not open "/etc/tor/torrc": Permission denied 2) with TBB, after I started TBB, if I run example.py, it seems it can connect to ControlPort, but it prompts for a password there is a Data directory in TBB, but I can't find the so called " control_auth_cookie" file, so when I run TBB, how can I pass "--CookieAuthentication 1" to tor? example.py : import time import TorCtl class BandwidthListener(TorCtl.PostEventListener): def __init__(self): TorCtl.PostEventListener.__init__(self) def bandwidth_event(self, event): print "tor read %i bytes and wrote %i bytes" % (event.read, event.written) # constructs a listener that prints BW events myListener = BandwidthListener() # initiates a TorCtl connection, returning None if it was unsuccessful conn = TorCtl.connect() if conn: # tells tor to send us BW events conn.set_events(["BW"]) # attaches the listener so it'll receive BW events conn.add_event_listener(myListener) # run until we get a keyboard interrupt try: while True: time.sleep(10) except KeyboardInterrupt: pass

2 1

Working on GUI
by vimalathithan 08 Nov '12

08 Nov '12

Hi, I am new to this community. A group consists of 5 members from School of Informatics and Computing, working with Professor Jean Camp on a research paper. Our research is to carry out a case study after making changes in the UI of Tor Browser. Could anyone here, please provide a link to learn more about Tor UI to get started with the development activities. Also it would be of great help, if some related document are shared. Please apologize me, if I posted my query to a wrong mailing list or my query sounds naive. Regards, Vimalathithan Rajasekaran Graduate Student - Computer Science School of Informatics and Computing Indiana University - Bloomington

9 11

Proposal 213: Remove stream-level sendmes from the design
by Roger Dingledine 06 Nov '12

06 Nov '12

Filename: 213-remove-stream-sendmes.txt Title: Remove stream-level sendmes from the design Author: Roger Dingledine Created: 4-Nov-2012 Status: Open 1. Motivation Tor uses circuit-level sendme cells to handle congestion / flow fairness at the circuit level, but it has a second stream-level flow/congestion/fairness layer under that to share a given circuit between multiple streams. The circuit-level flow control, or something like it, is needed because different users are competing for the same resources. But the stream-level flow control has a different threat model, since all the streams belong to the same user. When the circuit has only one active stream, the downsides are a) that we waste 2% of our bandwidth sending stream-level sendmes, and b) because of the circuit-level and stream-level window parameters we picked, we end up sending only half the cells we might otherwise send. When the circuit has two active streams, they each get to send 500 cells for their window, because the circuit window is 1000. We still spend the 2% overhead. When the circuit has three or more active streams, they're all typically limited by the circuit window, since the stream-level window won't kick in. We still spend the 2% overhead though. And depending on their sending pattern, we could experience cases where a given stream might be able to send more data on the circuit, but it chooses not to because its stream-level window is empty. More generally, we don't have a good handle on the interactions between all the layers of congestion control in Tor. It would behoove us to simplify in the case where we're not clear on what it buys us. 2. Design We should strip all aspects of this stream-level flow control from the Tor design and code. 2.1. But doesn't having a lower stream window than circuit window save room for new streams? It could be that a feature of the stream window is that there's always space in the circuit window for another begin cell, so new streams will open faster than otherwise. But first, if there are two or more active streams going, there won't be any extra space. Second, since begin cells are client-to-exit, and typical circuits don't fill their outbound circuit windows very often anyway, and also since we're hoping to move to a world where we isolate more activities between circuits, I'm not inclined to worry much about losing this maybe-feature. See also proposal 168, "reduce default circuit window" -- it's interesting to note that proposal 168 was unknowingly dabbling in exactly this question, since reducing the default circuit window to 500 or less made stream windows moot. It might be worth resurrecting the proposal 168 experiments once this proposal is implemented. 2.2. If we dump stream windows, we're effectively doubling them. Right now the circuit window starts at 1000, and the stream window starts at 500. So if we just rip out stream windows, we'll effectively change the stream window default to 1000, doubling the amount of data in flight and potentially clogging up the network more. We could either live with that, or we could change the default circuit window to 500 (which is easy to do even in a backward compatible way, since the edge connection can simply choose to not send as many cells). 3. Evaluation It would be wise to have some plan for making sure we didn't screw up the network too much with this change. The main trouble there is that torperf et al only do one stream at a time, so we really have no good baseline, or measurement tools, to capture network performance for multiple parallel streams. Maybe we should resolve task 7168 before the transition, so we're more prepared. 4. Transition Option one is to do a two-phase transition. In the first phase, edges stop enforcing the deliver window (i.e. stop closing circuits when the stream deliver goes negative, but otherwise they send and receive stream-level sendmes as now). In the second phase (once all old versions are gone), we can start disobeying the deliver window, and also stop sending stream-level sendmes back. That approach takes a while before it will matter. As an optimization, since clients can know which relay versions support the new behavior, we could have relays interpret violating the deliver window as signaling support for removed stream-level sendmes: the relay would then stop sending or expecting sendmes. That optimization is somewhat klunky though, first because web-browsing clients don't generally finish out a stream window in the upstream direction (so the klunky trick will probably never happen by accident), and second because if we lower the circuit window to 500 (see Sec 2.2), there's now no way to violate stream deliver windows. Option two is to introduce another relay cell type, which the client sends before opening any streams to let the other side know that it shouldn't use or expect stream-level sendmes. A variation here is to extend either the create cell or the begin cell (ha -- and they thought I was crazy when I included the explicit \0 at the end of the current begin cell payload), so we can specify our circuit preferences without any extra overhead. Option three is to wait until we switch to a new circuit protocol (e.g. when we move to ntor or ace), and use that as the signal to drop stream-level sendmes from the design. And hey, if we're lucky, by then we'll have sorted out the n23 questions (see ticket 4506) and we might be dumping circuit-level sendmes at that point too. Options two or three seem way better than option one. And since it's not super-urgent, I suggest we hold off on option two to see if option three makes sense.

3 7