- tor-dev - lists.torproject.org

Tor Censorship Detector: Can I help?
by Sam Burnett 13 May '13

13 May '13

Hi, I'd like to help improve the Tor Censorship Detector. I've read some background material and think I understand the basics of George Danezis' detection algorithm [1, 2]. Is anyone still working on this? Two tickets from a year ago talk about experimenting with various detection algorithms and turning one of them into a standalone utility [3, 4]. Has anything happened since then? My background: I'm a graduate student at Georgia Tech studying network censorship circumvention and measurement. Although I've met Tor developers on various occasions, I haven't directly contributed to the project; I'd like to change that. Thanks! Sam [1] https://lists.torproject.org/pipermail/tor-dev/2011-September/002923.html [2] https://metrics.torproject.org/papers/detector-2011-08-11.pdf [3] https://trac.torproject.org/projects/tor/ticket/3718 [4] https://trac.torproject.org/projects/tor/ticket/4180

3 3

Re: [tor-dev] Iran
by monet＠tormail.org 10 May '13

10 May '13

Is any IP6 in Iran? IP6 is blocked too?

1 0

Channel incoming queue
by MF Nowlan 09 May '13

09 May '13

Hi all, I am working on integrating uTCP and uTLS ( http://arxiv.org/abs/1103.0463) into Tor to see if we can lower the latency due to head of line blocking across circuits. This is Tracker Item #7679 ( https://trac.torproject.org/projects/tor/ticket/7679) I want to first test the Tor code's ability to process cells from different circuits out of order with respect to how TCP delivered them. To test this, I made some changes to the file named src/or/channel.c. 1. I forced queueing of cells into the channel's incoming_queue with: channel_queue_cell(...) { ... need_to_queue = 1; // Force all cells into the queue, so they do NOT go directly to the handler. ... 2. Now, look for case when two cells from different circuits are present in the incoming_queue and process the second cell before the first cell. channel_process_cells(...) { ... while (NULL != (q = TOR_SIMPLEQ_FIRST(&chan->incoming_queue))) { // Remove q from the incoming_queue. // if the queue is still not empty, get the next one, // if the circuit ids do not match, Swap the cells. } ... } My problem is that number 2. above never occurs. I have not observed a case where the incoming_queue ever has two cells from different circuits. In fact, I don't think I've ever had a time when the incoming_queue has more than 1 cell in it. I am hammering a small tor test network with 30+ curl requests at once. I have two proxies, each of them uses the same entry node, and the same exit node, and there is only one other node in the network, so the circuit that is set up should be the same for every single request. Am I missing something? Will this function (channel_process_cells) ever process more than one cell at a time? I've checked the logs to verify that different circuits are actually set up for the different requests (rather than the Proxies just reusing the existing circuit and giving each new request a new stream id). Thanks for the help! Fitz

3 4

Iran
by Nima 09 May '13

09 May '13

Iran is actively dropping connections to *any* unknown port right after *60secs*. Pluggable Transport successfully connects to Tor network, Although it can not make a circuit in many ISPs including "Mobin". -- Nima 0x1C92A77B "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

9 14

Re: [tor-dev] LibOnionRoute released
by wac 06 May '13

06 May '13

On Mon, May 6, 2013 13:59 EDT Jeroen Massar wrote: >On 2013-05-06 19:45 , wac wrote: >> >> Hi folks: >> >> For all those interested I made an Initial release of the >> modification that transforms Tor into a library. The former libTor >> renamed to libOnionRoute. Windows only so far. >> >> You can download at: >> >> http://www.onionroute.org/downloads/ > >As your code is based on Tor and that evolves, continuously especially >regarding security fixes, other updates and newer features, is there a >git-branch somewhere so that the changes you are making are visible? The changes compared to Tor are still not that big with all due intention. I made them that way in order to ease migration to a new Tor release and/or include changes coming from Tor easily. Be able to keep up. As matters of fact you can still get a Tor binary out of the sources (or almost, this wasn't tested) if you undefine the LIBRARY macro. Also so people can study them easily. The changes are more source code study than actual modification. I do however understand that commits are more descriptive. If you do not understand one of the modifications just ask me, I can tell you what does the change to alleviate the lack. As for Git, we are planning to move the repository to GitHub as we are looking to make this a community process. Review and include pull requests. Don't worry, I released that way because is faster not because being the best. Many people was requesting the source code, to the point that some guessed the sources archive name out of the binary archive. And downloaded it before being published at the website. This way they can be studying the sources in parallel while I work in other areas other than coding. I will not be fixing bugs in Tor ATM but I expect that by the time sources to be in a Git repository. As matters of fact I plan to move the changes to the next Tor release and if is not stable, work on it to make it that way. Maybe coordinated with Tor developers. Regards Waldo > >Greets, > Jeroen

1 0

LibOnionRoute released
by wac 06 May '13

06 May '13

Hi folks: For all those interested I made an Initial release of the modification that transforms Tor into a library. The former libTor renamed to libOnionRoute. Windows only so far. You can download at: http://www.onionroute.org/downloads/ Regards Waldo

2 1

Damian's Status Report - April 2013
by Damian Johnson 06 May '13

06 May '13

Hi all. Though April had a bit of stem work the month was mostly gobbled up by the chaos that is GSoC [1]. I never cease to be amazed at how much time orchestrating it takes, but enough of that. Other tasks from last month included... Improved Stem's Site * Added a change log for user facing improvements [2] * Added a FAQ, suggestions for more entries welcome! [3][4] * Improved navigability via a css style navbar menu [5] * Site logo and faveicon * Thanks to Dererk stem is now in Debian [6], and will soon be in Fedora too thanks to Juan * Put stem on tor's front page to improve discoverability [7] General Stem Improvements * Overhaul for a large part of our testing framework, run_tests.py in particular was in need of a rewrite [8] * Fix for broken process renaming (patch from ragwater [9]) * We now have a custom :trac: and :spec: role for Sphinx (patch from ragwater [10]) * ATTACHSTREAM provided an unexpected 555 response (caught thanks to a cypherpunks [11]) * Added support for the ADDRMAP event's new CACHED attribute * Looked into anomalous bridge-ip-transports lines in the consensus, turned out to be from an unmerged tor patch running on George's relay Cheers! -Damian [1] https://blog.torproject.org/blog/tor-google-summer-code-2013 [2] https://stem.torproject.org/change_log.html [3] https://stem.torproject.org/faq.html [4] https://trac.torproject.org/8577 [5] https://trac.torproject.org/8431 [6] http://packages.debian.org/sid/python-stem [7] https://lists.torproject.org/pipermail/tor-commits/2013-April/055091.html [8] https://gitweb.torproject.org/stem.git/commitdiff/ae5193f?hp=314876a [9] https://trac.torproject.org/8631 [10] https://trac.torproject.org/8671 [11] https://trac.torproject.org/8701

1 0

Tor Launcher settings UI feedback request
by Mark Smith 05 May '13

05 May '13

As many of you know, Kathy Brade and I have been working on a Firefox add-on named Tor Launcher, which will function as a Tor process manager and controller for TBB (replacing Vidalia). See: https://trac.torproject.org/projects/tor/ticket/6009 Currently, Tor Launcher provides access to the basic Tor network settings that are needed by TBB users. We would like some feedback on the Network Settings dialog (accessible from within the browser after it starts up) and on a "first run" wizard that we have created based on a suggestion from Greg Norcie. A collection of screenshots is available here: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/ If you are in a hurry, just look at these two: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/FromBrowser/netwo… (settings dialog as seen from inside the browser) http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/wizar… (composite of all of the wizard panels). Thanks to everyone who has provided input so far. -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/

11 21

RELAY_COMMAND_END formate
by Frank Young 03 May '13

03 May '13

The payload format for RELAY_COMMAND_END and RELAY_DATA are not details in the tor protocol specifications. where can i get the payload format for these relay cells? Thanks

2 2

GSoC 2013 project idea
by Sreenatha Bhatlapenumarthi 03 May '13

03 May '13

Hi, My name is Sreenatha Bhatlapenumarthi (lucyd). I am a third year computer science undergraduate at IIITH. I am interested in participating in GSoC'13 with Tor. I've begun by submitting patches for stem tickets #7505, #8605 and #7713. I'd like to propose a new idea for a project with a blend of stem, TorBEL and pyobfsproxy. I've split the project into 3 modules. 1. Fix stem bugs and add new features if possible Although I can't think of any new functionality to add to stem(other than what Damian suggested) at this point of time, there are some bugs that need to be fixed. I went through the tracker and picked some stem-related bugs I'd like to fix as a part of the project. Please feel free to suggest new bugs or let me know if you think any these are of low priority and don't need to be included in the project. - #7910 (Port some of arm's connection utilities to stem) - #8255 - #8248 - #8249 2. Migrate TorBEL to Stem [0] This will involve porting TorBEL from TorCtl to Stem and making modifications to the stem API if necessary. Hopefully after fixing the bugs mentioned above, I'd have a better understanding of how stem works and I'd be able to do a better job. 3. Implement HTTP pluggable transport for pyobfsproxy I can think of two ways of doing this - Develop an actual pluggable transport for obfsproxy to impersonate HTTP traffic. I've looked at obfs2's protocol-spec and its python implementation and I think this would involve writing a separate module implementing the transport with a template similar to that of DummyTransport[1]. - Use a browser engine like webkit on client-side and a web server on the server-side as mentioned at ticket #8676[2]. Here are a couple of questions I have regarding the project: - What are the priorities of the modules I've proposed? - Do you think the project has enough scope and material for a SoC project? If not, can you please suggest some more features to add? - If the project seems overloaded, which module(s) do you suggest I drop? I would love to hear your opinions on these matters. If there's something you want me to take a look at or study, please do let me know. Thank you for your time. [0] - https://trac.torproject.org/projects/tor/ticket/8263 [1] - https://github.com/lucyd/obfsproxy/blob/master/obfsproxy/transports/dummy.py [2] - https://trac.torproject.org/projects/tor/ticket/8676 Cheers, Sreenatha

2 2