- tor-dev - lists.torproject.org

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

SQLSupport
by moataz ahmed 03 May '13

03 May '13

is it possible to insert data about routers,circuits and bwhistory in database ? i am using opaddon to measure relays and i can see in torctl folder that there is a file called sqlsupport.py he is using sqlalchemy to deal with database i ran opaddon many times but there is no insertion in the database !!! any help ?

2 1

[possibly OT] Updated giant inventory of headers available on various OSes
by Zack Weinberg 02 May '13

02 May '13

A while ago I posted a call for help (only to autoconf@) taking inventories of which C headers are provided by which OSes. It rapidly became clear that my methodology was far too crude, and I've spent much of the past six weeks coding up something much more sophisticated. The project is now at the point where I feel comfortable sharing it with a wider audience. Please see http://hacks.owlfolio.org/header-survey/ for the results so far, and https://github.com/zackw/header-survey/ for code, raw data, and instructions for contributing inventories for OSes not yet in the big table. (Big table only known to work properly in Firefox, say sorry - patches for the bad stylin' in Webkit most welcome. I've exhausted my ability to sling CSS.) If you sent me an inventory already but your OS is not in the big table, I need you to send it again using the current `scansys.py`. To those of you who told me that it didn't work with your version of Python, take heart - it is now tested to work with 2.0. Yes, 2.0. zw

1 0

Cell digest of relay cells destined for hidden services
by Frank Young 02 May '13

02 May '13

The digest of relay cells are running digests [ SHA_final() is never called ], so the digest of each cell is dependent on the previously computed digest destined for that node particular node. Hashing is seeded with values determine by the OR which responded with CREATED or REALY EXTENDED cell. I have noticed that, the payload of RELAY_COMMAND_RENDEZVOUS unlike CREATED OR RELAY EXTENDED cells made no provisions for the seeding bytes. This can be referenced in section 1.10 of https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.… I'm in a state of confusion concerning how the digest of relay cells destined for hidden services should be computed. [1] should the digests be independent of previously computed digests destined for the hidden services? OR [2] it should be a running digest but not seeded with any seeding value. I will like a little clarification on this. Thanks

2 1

ping
by wac 01 May '13

01 May '13

ignore please

1 0

Re: [tor-dev] Stem Integ tests for Tor
by Ashish Patil 01 May '13

01 May '13

On Mon, Apr 29, 2013 at 17:44 PM, Nick Mathewson <nickm at alum.mit.edu> wrote: > Right now, all chutney > does is configure and launch a small Tor network, but the small > network requires a little babysitting to make it bootstrap. (For > example, you sometimes need to send the clients a SIGHUP once the > authorities have made their first consensus. So, the first bits for improving chutney would be to automate the network generation as much as possible (leaving no loose ends)? > What Chutney doesn't do (but should!) is actually test the network it > launches. Right now, to make sure the network has bootstrapped, you > have to read through its log files. If you want to test the network > with any traffic, you need to use an application of your choice to > send traffic through one of the Tor clients, and verify that the > output as is expected. And if you want to make sure that Tor is > running without weird warnings, you need to manually inspect the > log files again. It would be good if Chutney grew into, or were > replaced by, a tool that could actually do testing right that. Now, we want chutney to be robust enough to encompass all the manual that is mentioned above & automate it as much as possible or atleast print the tasks to be performed by the tester sequentially. We would need a set of static reliable web pages if we want to automate the traffic testing? Also, we would parse the log files for errors or warnings so that we dont have to manually check for them. * Construct a circuit to an exit which allows port 80 and request a site through it. * Do the same for an exit which rejects port 80. * Construct a one-hop circuit through an exit. * Try to use a circuit that runs through a bridge. * Let tor pick the path of a circuit and assert that the first relay's a guard and the last is an exit. * Attempt to request a page from a hidden service. * Host a hidden service and request something from ourselves. * Act as a relay and try to construct a circuit that includes ourselves. * ... etc... As Damian listed down all the tests one needs to carry out for actual network testing (keeping in mind unreliability of the network at times), what all additional tests would we like chutney to have?

3 3

GSoC Deadline Reminder
by Damian Johnson 01 May '13

01 May '13

Hi all. If you're a prospective Google Summer of Code student and haven't yet submitted a proposal then please do so now. The deadline is Friday (May 3rd). You'll be able to edit your proposal up until the deadline so there's no reason not to submit something early. If you don't submit a proposal on time then it doesn't matter how great of an idea you have - we'll be unable to accept it. -Damian

1 0

GSOC - Internet Censorship Virtual Machine Based Simulator
by Claudiu Perta 01 May '13

01 May '13

* Hi Tor team, I'm Claudiu, a second year PhD student in CS at Sapienza University (Rome, Italy) and I would like to work on your GSOC idea to build a VB-based simulator for OONI. My main research topics are network neutrality and broadband measurement and I'm currently working on a project on traffic shaping detection. I also partecipated to last year GSOC when I developed in Python a server selection mechanism for M-Lab ( https://code.google.com/p/m-lab/source/browse/?repo=ns) I've worked in the past with Netkit ( http://wiki.netkit.org/index.php/Main_Page<http://wiki.netkit.org/index.php/Main_Page>) and I think it meets all the requirements of this GSOC project. Netkit is an open source project,based on user-mode linux[1], a linux kernel that can be executed as a user process on a standard linux box. In particular, each virtual machine in Netkit can be configured to play the role of a regular host, of a router, or even of a switch. For this project, each test could be set up as a ‘netkit lab’, which is a set of preconfigured virtual machines that can be started and halted together. For example, one virtual machine running ooniprobe could be connected to the external world through a second virtual machine that implements various censorship policies, specific to each test. Regards, Claudiu [1] http://user-mode-linux.sourceforge.net/ *

3 3

New Google Summer of Code idea
by Milosz Godlewski 30 Apr '13

30 Apr '13

Greetings everyone, I want to share with you my idea to increase security. I would like to create a add-on to the Tor Browser Bundle application, which will ensure protection and control of out- and in- connections. That add-on will enable setting a maximum time of data transfer between the user and the web, thus we can radically improve the privacy of user in web. For this purpose we are going to add one of open source firewall to the Tor Browser Bundle application. This extension will inform the user about request of connection and then, dependently on the user’s choice will block (or not) whole in- and out- traffic, in order to allocate time of execute into every web site (every server) in a bookmark, Firefox or Flash animation. After the report of connection request trough any web application, it would be possible to add the maximal time, gave to the application for data transfer. It gives the possibility to block the unlike sending and downloading information in the background, for example after receiving whole content of the site. Example: block the chat in Facebook or block the execution of application, working in the background (bootnet type) It could be also possible to set a temporary time of blocking OR unblocking applications ( in future maybe also external). This application can start working on the console, but it’s worth to add pop out information after some time. In the other window it will be possible to show a list of active applications (which actively downloading data) in order to unfold and “take a look” which card is downloading files from server. In other words we would like to block all applications’ access to the internet without the users knowledge, when Tor works. Hope you will like it :) Miłosz Godlewski

1 0

Improving the HTTP interface of BridgeDB: bridges.torproject.org
by George Kadianakis 30 Apr '13

30 Apr '13

Hi list, it's high time to write a better website for https://bridges.torproject.org since it currently looks like the homepage of an academic professor. The new website should promote the use of pluggable transports (over normal bridges) and should be explanatory and friendly to end-users. I started writing a skeleton and some strings for the new website. I'm also attaching an image of how the website looked like in my head while I was writing the strings (although the person who codes, should choose the interface). Sathya (cc'ed) said that he would be interested in coding the web part. The relevant trac ticket is https://trac.torproject.org/projects/tor/ticket/7296 . If you have ideas on making the web frontend (or my proposed strings) better, please write them there. Thanks!

10 18

GSoC 2013: Enable flashproxy to use WebRTC
by Danilo Carvalho 30 Apr '13

30 Apr '13

Hello, My name is Danilo Carvalho, I am from ITA, Brazil, and I'm thinking about enabling flash proxy to use WebRTC, specially Data Channels, to connect between the client and the flash proxy. Some of the benefits involved would be: 1 - Flash proxies now would be able to receive incoming connections, this would remove the current need for the flash proxy to connect to the client. With the client being able to connect to the flash proxy, ticket( https://trac.torproject.org/projects/tor/ticket/5426) would be solved. If the client is the one controlling the connection, it wouldn't be needed for the flash proxy to guess his usage time. 2 - We could use the built in resources of the WebRTC to do nat traversal, through ICE and STUN servers. Although it isn't quite right to use public, company-owned ICE and STUN servers for that, we could build that functionality into the flash proxy, allowing the ones that are not behind nat to work as STUN and ICE servers for the others. Also, with the WebRTC already in use, it would be easy to port to NAT-PMP or UPnP, with I believe will be integrated into it in the future. Now, on the regards of how well spread WebRTC is, it's already built into Firefox and Chrome, and they both interoperate( http://blog.chromium.org/2013/02/hello-firefox-this-is-chrome-calling.html) On how much work it would demand: Some work would be required to enable the use of WebRTC in the javascript part of the flash proxy, and probably some parts will require rewriting, since the flash proxy will not operate in the same way anymore. The client plugin will need big changes, since it will need to connect via Data Channels, that is not trivial( https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-04#section-1) and most of the controlling would be done there. On the facilitator part, I believe only minor parts will require change, mostly to handle the flash proxy address giveaway(It should be controlled in some way, else an attacker could keep polling enough address to know the majority of them). Well, that's about it, I'll be pleased to hear your opinions about it, Greetings, Danilo

2 1

GSoC 2013 / Tor project ideas - Searchable Tor descriptor archive - (pre-)proposal
by Kostas Jakeliunas 30 Apr '13

30 Apr '13

Hello Karsten and everyone else :) (TL;DR: would like to work on the searchable Tor descriptor archive project idea; considering drafting up a GSoC application) I'm a student & backend+frontend programmer from Lithuania who'd be very much interested in contributing to the Tor project via Google Summer of Code (well, ideally at least; the plan would be to volunteer some time to Tor in any case, but it's yet to happen, and GSoC is simply too awesome an opportunity not to try) - The 'searchable Tor descriptor/metrics archive' project idea [1] would, I think, best fit in with my previous experience and general interests in terms of contributing to the Tor project. The searchable archive project idea in itself has a rather clear list of goals / generic constraints, and since I haven't contributed any code to the Tor project before, working with an existing general project idea (building a more concrete design proposal on top of it) probably makes most sense. This particular project, I think, would match my previous Python backend programming experience: building backends to work with large datasets / databases -- crafting efficient ORMs and responsive APIs to interact with them. [2] Applying the knowledge/skills learned to something which is ideologically close at heart and the purpose of which is very obvious to me sounds thrilling! (This year, as far as Python frameworks are concerned, I've been mostly exposed and have been working with Flask - have some (limited) experience with Django before that. As far as a proof-of-concept for the searchable archive is concerned, I'm considering trying some things out with Flask, since it allows me to do some quick prototyping.) I'd like to try and work out an implementation/design draft for what I could / would like to do (this is a preliminary email - I know I'm a bit late!) Ideally it (and a simple proof of concept search form -> browseable/clickable results / relay descriptor navigation page) would serve as the base for my GSoC application, but I have to be realistic about me being rather late to apply and not having participated in neither Tor nor GSoC before. I'd like to work out an application draft if possible, though. (Were I to get accepted, I would be able not to do any part-time work this summer, or would only need to take passive care of a couple of already running backends.) I've read into the Tor Metrics portal pages (esp. Data Formats), and am trying to get acquainted with the existing archiving solution (reading into the 'metrics-web' java source (under metrics-web/src/org/torproject/ernie/web) to see how the descriptor etc. archives are currently parsed / imported into Postgres and so on), to first and foremost be able to evaluate the scope of what I'd like to write. I will presently work on a more specific list of constraints for the searchable archive project idea. I can then try producing a GSoC application draft. Just to get an idea of what kind of system I'd be building / working on - at the very least, we'd be looking into: - (re)building the archival / metrics data update system - the proposed method in [1] was a simple rsync over ssh / etc. to keep the data in sync with the descriptor data collection point. If possible, it would help if the rsync could work with uncompressed archives - rsync is intelligent enough not to need to send *that* much excess data - and diffing is more efficient with uncompressed data. A simple rsync script (can be run as a cron job) would work here. - a python script (probably to be run through cron) to import the archives into DB. Can stat files to only need to import new/modified ones, e.g. The good thing about such an approach is that the script could work as a semi-standalone (would still need the DB / ORM design), therefore could be used in conjunction with other, different tools - and it would be built as an atomic target during the implementation process - I heard you guys like modular project design proposals ;) who doesn't like them! We already have metrics-utils/exonerator/exonerator.py (which works as a semantically-aware descriptor archive grep tool) - some archive parsing logic can be reused maybe - the more pertinent thing here would be to - build the ORM for storing all the archival data in DB. Postgres is preferred and could work, especially since probably the a large part of the current ORM logic could be used here (I've taken a glance at the current architecture, it makes good sense to me, but I haven't looked further, neither have I done any benchmarking with the existing ORM (except for some web-based relay search test queries which don't really count.)) - it is very important to build an ORM which would scale well data-wise, and would suit our queries well. - query logic and types - the idea would be to allow to do incremental query-building - on the SQL level, WHERE clauses can be incrementally attached to the higher-level ORM query object. For example, part of fingerprint / relay name -> add a date interval -> additionally, add a day-specific "on date" clause -> etc. ORM efficiency, benchmarking and restrictions on query complexity - this may turn out to very much be a nontrivial matter. - on the user interface level, user query input parsing - the idea would be to allow for flexible user input; date interval / info not mandatory; possibly, the user may provide additional filtering by specifying more descriptor metadata. Would need to figure out the most accessible type of input - a simple input field with info about the flexible syntax with examples and a flexible parser, and/or optional additional fields - a responsive UI (can expand the input form into additional fields/options and try to avoid contradictory / non-sensical input) might prove effective here. - results page - would need to work out what kinds of relay metadata to show, can click on parts of the data on the results page to further narrow results - unless click on relay name / fingerprint / etc., in which case would be taken to that specific relay's page (on a more general sense, this would also be a kind of 'result narrowing.') - => generally create a browsable relay archive, formatting / aggregating specific descriptor fields to provide more info about each relay. <-- may make sense to start working on the particular constraint list starting from this point. Hopefully Karsten can help me with the application, assuming my idea for the project is to make sense. :) I will follow up with more details. Besides my email address < kostas(a)jakeliunas.com>, I can be reached on #tor-dev as 'wfn', or XMPP/Jabber via <phistopheles(a)jabber.org>. Cheers to you all Kostas. [1] https://www.torproject.org/getinvolved/volunteer.html.en#metricsSearch [2] My largest Python backend related project was this winter, building a redis (product likes/dislikes) + mysql (everything else) product recommendation solution to work with a large dataset of (product) metainfo (such as user votes on products), and creating APIs (on top of Flask) (API for the frontend CMS and for a mobile app) which include custom-per-user product recommendation feeds, etc. Large data (nothing close to the Tor descriptor/metrics archives, though!) + Interactive application logic architectures are of interest to me.

2 1

TorBEL migration
by Sreenatha Bhatlapenumarthi 30 Apr '13

30 Apr '13

Hi, My name is Sreenatha Bhatlapenumarthi. I'd like to migrate TorBEL from TorCtl to Stem as a part of GSoC'13 project this summer. Damian pointed out that there is still some improvement to be made to TorBEL to replace DNSEL. I've downloaded the source code from [0] and started looking around for missing functionality and components that use TorCtl(and hence need migration) and here is what I've observed: - TorBEL components that use TorCtl - Controller - control.py - Logger - logger.py - Router - router.py - Tests - tests.py - The main interface - torbel - Exit policies of narrow_exit routers can be checked in Router.will_exit_to[1] - RouterRecord.update_to()[2] can use "Router Status Entry" descriptors[3] to update the router's attributes - I think the following line[4] in network.py has a bug - socket.inet_aton works only for IPv4 addresses[5]. - (ip,) = struct.unpack(">I", socket.inet_aton(peer.host)) Please let me know if I've missed something or got something wrong. I donot have any background on Haskell as such but if you recommend that I learn it inorder to understand TorDNSEL, I am prepared to spend the required amount of time learning it during May before the coding period starts. Also, can you give me a rough estimate of how long you think the migration will take so that I can plan the project timeline accordingly? Thanks for taking your time out to read this. [0] - https://git.torproject.org/torbel.git [1] - https://github.com/lucyd/torbel/blob/master/query.py#L85 [2] - https://github.com/lucyd/torbel/blob/master/router.py#L125 [3] - https://stem.torproject.org/api/descriptor/router_status_entry.html#stem.de… [4] - https://github.com/lucyd/torbel/blob/master/network.py#L75 [5] - http://docs.python.org/2/library/socket.html#socket.inet_aton Cheers, Sreenatha

2 1

Stem Integ tests for Tor
by Ashish Patil 29 Apr '13

29 Apr '13

Hello everyone! I would like to improve on Tor's codebase by writing Integ tests for it in Stem. I would like to know what kind of tests should be included in this. Also, atagar was talking about smoke tests for Tor as a whole. I would love to know everyone's ideas on the same. Also, I would like to start a new project which can automatically download & compile latest Tor. This would greatly help with the Integ tests for Stem & Tor. -Asis

3 2

Fwd: HTTPS Server Impersonation project
by Akshay Hebbar Y.S. 29 Apr '13

29 Apr '13

Hi, I wish to do the project 'HTTPS Server Impersonation' as a GSoC project this year. For that, I propose an approach for implementation. I would like to use Nginx as reverse proxy. Because nginx is very widely used and it is known for its high performance, stability and low resource consumption. Once this is used, this will become the interface for Bridges. All connections to the bridge will be listened on port 443. Two back-end servers for this reverse proxy : 1. Tor itself 2. Web server A special module has to be written for handling the requests. Once the request is authenticated, it will be sent to tor process. Otherwise, it will be sent to web server and suitable response is sent back. Once the new tor client finishes its handshake, its IP address will be mapped to Tor in nginx 'Load Balancer'. Further requests from that IP address will be sent to the Tor directly. How does a bridge distinguish between Tor client and attacker? For this, I need suggestions to select one among the following. 1. Use AUTHORIZE and AUTHORIZED cells as discussed in proposals #187 and #189 2. Provide a public key while giving the bridge address. I.e. When someone requests a bridge address, provide [IP ADDRESS] + [PORT] + [PUBLIC KEY] [ here port = 443 ] Once the client gets the public key of bridge, it can encrypt its data send to bridge. Bridge uses its private key to decrypt the message, and hence only bridge can decrypt the message. If the message received has proper headers it will be sent to tor, otherwise it will go to the default web server. What will the web server contain? Web Server will have some pages which makes the website look like 'online storage site' or 'Online gaming site' or 'social networking site' or something like that. Because a passive attacker can wonder what the client is sending/receiving from a website which looks like 'blog'! Hence from the above discussion, we can achieve the goals of project: a. Impossible for a passive attacker who examines only a few packets at a time to distinguish Tor->Bridge traffic from an HTTPS client talking to an HTTPS server Tor client -> bridge connection will be TLS. So he can't distinguish b. Impossible for an active attacker talking to the server to tell a Tor bridge server from a regular HTTPS server Every ill-formed request will be handled by Web server. c. Against MITM attack If AUTHORIZE and AUTHORIZED cells are used, I need some help in making it preventing MITM attack. If method 2 is used for authentication, MITM attack can be easily prevented. Because even though the attacker receives the packet, he can't decrypt the message since he doesn't have key for decrypting it. Tor client sends this message along with its public key. Hence the bridge can encrypt and send back its response. Once the TLS connection is established then attacker will behave like hop in communication d. Code changes to tor It will be minimum and we just need to implement authorization code. e. Efficiency Once the new client completes its handshake, its IP address will be added to whitelist. Any packets from a client which is in whitelist will not be authenticated by the handlers in nginx. It will be directly sent to Tor process. Please correct me wherever I'm wrong and please give me suggestions to improve it. Thank you -- Akshay Hebbar Y S 6th sem, PESIT-CSE

2 1

About GSOC 2013 Steganography Browser Addon project idea
by Hareesan 29 Apr '13

29 Apr '13

Hey there, I'm Hareesan, undergraduate from University of Moratuwa,Sri Lanka. Interested in working on the project Steganography Browser Addon. I wish to confirm is that a project for GSOC? and Is it a good time to start working on my proposal? I have already gone through few chapters of the paper (Message In A Bottle: Sailing Past Censorship<http://www.cs.kau.se/philwint/censorbib/#Invernizzi2012>) a bit. -- *Hareesan R Undergraduate Department of Computer Science And Engineering University Of Morat**uwa Sri Lanka**** *

3 4

Re: [tor-dev] Stem Integ tests for Tor
by Ashish Patil 29 Apr '13

29 Apr '13

Hi! Thanks atagar, your reply cleared up a lot of things. I am going through the present integ tests in Stem & would contact you if I have any doubts. As for chutney, I suppose nickm's copy of chutney would be the one with most updates (if different from the default copy). I will go through that as well & let you know how much I grasped from it & what all needs to be done further as you mentioned in the reply. Thanks! -Asis

1 0

Re: [tor-dev] Stem GSoC 2013
by Tomasz Kunikowski 29 Apr '13

29 Apr '13

Hey, I favor GSoC projects that are collections of small items rather than a single big one (that way the incremental pieces are helpful, even if the project isn't quite fit into the summer). > We're on the same page here, I think more tasks of a smaller scope is the way to go. The next area I was planning to primary focus was client migrations, > which would involve work with TorBEL and Tor Weather... > I've looked through both TorBEL and Weather and while undoubtedly they could use some love, I think I'll follow my heart and stick with Stem :) Please don't take my ambiguity in regards to any concrete ideas as lack of interest on my side - it's that the more I learn about Stem (and I try to dedicate it most of my free time) the better I can assess its current needs and areas of lacking and come up with something substantial. As far as tutorials go, I was thinking about dealing with manual stream attachment (as a follow up to #8728), exploring more operations on circuits i.e. tearing down, forcing hops through specified countries or address ranges (maybe a more robust example as an excuse to come up with good use cases for REDIRECTSTREAM and TRUNCATE). As for the Stem itself, I'd love to work on adding any missing functionality (against the Tor protocol or expanding the lib itself), but I'd like to hear your suggestions where the real priorities and missing spots are first. Thanks, Tom

3 7