- tor-dev - lists.torproject.org

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