- tor-dev - lists.torproject.org

Obfsproxy client for Android
by Nathan Freitas 12 Feb '12

12 Feb '12

Thoughts on attempting to port and ship Obfsproxy client functionality to Android? We have a good number of Iranian users it seems, and I think we can pull it off in a few days, if it isn't insanely complex. Where should we begin? Any details on exactly what was done for the new TBB? +n

2 4

First test "report"
by Esteban Manchado Velázquez 12 Feb '12

12 Feb '12

Hi there, I'm done with the first batch of work on the test side. You have the (rebased just now) work here: https://github.com/emanchado/tor/commits/master. The rest of this e-mail summarises what I've done and explains my plan for further work. The content of the commits -------------------------- I have reviewed the whole test_util.c and made three kinds of changes: 1. Added more tests. Some of them failed, and after checking with other people on IRC the conclusion seems to be that they should pass (ie. they reproduce actual bugs in the code). To keep the test suite from failing, they are inside "#if 0" blocks. So someone should look for "#if 0" inside test_util.c and fix the code that makes those fail. Or maybe I should file bugs for those? 2. In comparison assertions, the general convention seems to be to place the expected value first ("test_eq(0, functioncall(...))" rather than "test_eq(functioncall(...), 0)"). I have modified the assertions not following that convention, so they all look the same. 3. General clean up, small code reorganisations, fix typos and such. Eg, I have turned all the "tt_int_op(a, ==, b)" into "test_eq(a, b)". I was thinking of blogging about what I saw (esp. related to point 1). I think there are valuable lessons to be learned, which will help other people writing tests (both for Tor and outside of Tor). I'm not sure if there's enough content for a blog post, but if I do it after all, should I post the link here? Plan for the future ------------------- As I haven't explored coverage yet, I'll start with that for the code in src/common/ and see what I can do. My gut feeling (without having looked at other parts of the code yet!) is that tackling unit tests for code in src/or/ will be hard for me, and it seems better to explain what kind of things I have done in src/common/ so others, more familiar with that code, can fix/improve the unit tests for src/or/*. In other words, it seems much more effective for me to support someone who knows the code in src/or/*, rather than the other way around. After I'm done with what I think is easy enough for me to do with the unit tests, I'll have a look at Stem (Damian's suggestion) and chutney (Nick's suggestion), and decide what I do next. -- Esteban

3 3

Tor developers: completed translations now in separate directories
by Runa A. Sandvik 09 Feb '12

09 Feb '12

Hi everyone, The latest version of the Transifex client allows users to specify a minimum percentage of completeness for the translations to be accepted by the client (that is, to be downloaded). The translation.git repository now has a _completed branch for each of our translation resources. If you only want to include 100% completed translations in your project, clone the _completed branch for your project from now on. -- Runa A. Sandvik

1 0

Proposal xxx: Safe cookie authentication
by Robert Ransom 07 Feb '12

07 Feb '12

See attached, because GMail would wrap lines if I sent it inline. Robert Ransom

3 7

Parallel Crypto - Library dep.
by David Goulet 03 Feb '12

03 Feb '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, To help the tor project, I'll contribute some of my spare time to improve multithreading for the Tor code base. I've speak a bit with Nick M. and it seems the crypto lib is an important part to begin with. The wiki page (https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/Multithreade…) indicates, basically, that a worker thread pool with a work queue to dispatch crypto events should be the right approach and I do agree. Is it acceptable to link an external library to the project being a dependence? The library I'm thinking about is "liburcu" which stands for user-space RCU (http://lttng.org/urcu) It's a complete set of lockless data structure including wait-free queue which can be very useful for our case. It support a large variety of architecture and works on BSD and Linux. The Linux kernel use RCU mechanism for a lot of internal data structure today so it's quite tested and solid. The question I think is do we want lockless data structure in Tor or it's not and will not be necessary for the type of workload ? (lockless re-sizable hash tables, red-black tree, stack, linked-list (double also) and queue are available as of today). Waiting on your feedback guys, either way, I'll begin implementing parallel crypto largely based on the wiki page (really good ideas there). Thanks a lot! David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJPKET6AAoJEELoaioR9I02OO0H/2lxrvak2ItAdGsXHsyH2dgz U3ePxZUg8Ix5UuZXA/LnP3T7/HBa47mtPMj3hwuz2Wnarf6FulumYA3A9jKsZyxQ tf6azD+G7CbZjjYPbe8XYfOZC6+x58mF7SciM/maLoFQLzCvw7ruBBXu8j0Ghw5Q hcm8RMIa4UyB0szSpMqkt615sYQBgy7hhEkNKqxnfdP4zIqUIK8mJqBING6r7qU+ EhnIT5VNzKG9FZPkYNzXOvzbtH0MegNfePsi6gDYlkjR7gekiT9wYH9n5tFTPQUu 4BwqaaHR/Wk+zfHaQOmz+KC3eefUqcd+XP82mcPTSUDj4mzG1Sio2ZHKX0IeJVw= =r0da -----END PGP SIGNATURE-----

4 7

Re: [tor-dev] Simulating a slow connection
by Rob Jansen 02 Feb '12

02 Feb '12

> Date: Thu, 26 Jan 2012 16:39:34 +0000 > From: Steven Murdoch <Steven.Murdoch(a)cl.cam.ac.uk> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Simulating a slow connection > Message-ID: <CAE309A8-034E-4E6A-B05C-6B9B3EA1CDBE(a)cl.cam.ac.uk> > Content-Type: text/plain; charset=us-ascii > > Hi Adam, > > On 20 Jan 2012, at 10:55, Adam Katz wrote: > >> Well, I myself didn't have anything specific in mind but i have some >> experience with the linux tc utility as well as with generating >> realistic background traffic. I was wondering whether I could help on >> any of the existing projects or help establish a new one. > > I think Nick's comments summarized the current state of thinking. ExperimenTor and Shadow are the best Tor simulators to use for this project. The big missing pieces are: > - an automated framework for setting up experiments with slow Internet connections with ExperimenTor and Shadow, then collecting and summarizing results > - Tools for generating realistic link characteristics (delay and packet dropping), and for collecting data on the link properties found in particular locations > > Steven. > As Steven stated, this would be very easy to explore with Shadow. The network topology is passed in as an XML file: node properties include bandwidth up/down and link properties include latency, jitter, and packetloss. I already have some python scripts to generate topologies, and would be happy to share them once you have realistic measurements/values for the slow links you'd like to explore. I'd also be happy to explain more about how Shadow works or the structure of the XML file. Rob

1 0

Extending BridgeDB to reallocate bridges from a blocked country to others that do not block.
by Aaron 02 Feb '12

02 Feb '12

The following is a draft proposal of changes to BridgeDB to address the deliverable "Automated bridge allocation to reallocate bridges from a blocked country to others that do not block" (https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorE/PhaseTh…) This draft proposes two different approaches -- any feedback or questions are very welcome! --Aaron ==== Filename: xxx-bridgedb-reallocates-bridges.txt Title: BridgeDB Reallocates Bridges Author: Aaron Gibson Created: 15 Jan 2015 Status: Draft Introduction: This proposal outlines the required changes for BridgeDB to reallocate bridges from a blocked country to others that do not block. Current Status: Presently, BridgeDB does not allocate bridges to specific countries. The HTTPS distributor divides bridges into a cluster of rings. Requests for bridges are mapped to a single ring in the cluster using the class C network of the client, so that the IPv4 space is divided amongst the rings in the cluster (presently 4 rings). For an attacker to obtain the complete set of bridges she must control a number of IP addresses in diverse networks. The email based distributor uses a single ring, and bridge buckets are dumped from a single pool of unallocated bridges. Required modifications: 1. BridgeDB must be able to produce an unblocked set of bridges for a specific country, if these bridges are available. 2. If a bridge is blocked in a country, it must be available to users in other countries. BridgeDB could be modified to assign bridges to geographic regions. To do so, the cluster concept must be extended to support 'geographic clusters' of bridges that correspond to a set of country codes, so that requests will be directed to a corresponding cluster, by either automatic geoip detection or by client choice. Alternately, BridgeDB could be modified to guarantee that a client requesting unblocked bridges for a region would receive these bridges, if unblocked bridges exist. Presently, patches exist for BridgeDB that mark known blocked bridges as "Might be blocked", but makes no further effort to respond with unblocked bridges, even if those bridges exist. Proposed Solution 1 Modify BridgeDB to assign bridges to geographic regions. Regions are designated by a list of country codes. Regions should be balanced in size, or proportional to the number of bridge users. If a bridge is blocked in a region, the bridge should be reallocated to another region. Bridges for a region are stored in a cluster of rings. Pitfalls Bridges assigned to one geographic area are not available to clients requesting bridges from other regions. Possible Solution 2 Modify BridgeDB to dynamically produce rings of bridges 'Not blocked in' a specified country. Bridges are not mapped to a specific country or region, but BridgeDB's response would contain only unblocked bridges (if available). Pitfalls As bridges are not allocated to a specific region, bridges could not be reserved for distribution to specific regions. Common pitfalls As BridgeDB learns about blocked bridges that it may no longer provide, BridgeDB replaces blocked bridges with good bridges. An attacker with control over addresses from many class C networks could iteratively request and block bridges, until the entire set has been consumed. The rate of consumption could be limited by the rate that blocked bridges are updated, but clients would be more likely to receive a bridge that has been blocked.

2 2

DNS/DNSSEC resolving in Tor (PoC implementation)
by Ondrej Mikle 01 Feb '12

01 Feb '12

Hi, I decided to give it a shot in implementing full DNS/DNSSEC resolution support for Tor, here's the branch: https://github.com/hiviah/tor ATM the biggest limitation is that reply DNS packet must fit in a single cell (i.e. max size is RELAY_PAYLOAD_SIZE). How it's implemented: There's new command SOCKS_COMMAND_RESOLVE_FULL for SOCKS interface and new cells RELAY_COMMAND_RESOLVE(D)_FULL. The RESOLVE_FULL cell contains query string and RR-type, RESOLVED_FULL just the DNS packet in wire format. Resolving is implemented via libunbound on the relay's side, ldns parses packet on client's side. The tor-resolve now uses the new SOCKS command and accepts -t parameter with RR-type (numeric, default 1 - RR-type 'A'), e.g.: ./src/tools/tor-resolve -t 28 lupa.cz localhost:10050 Packet size: 319 Flags: qr: 1, aa: 0, tc: 0, rd: 1, cd: 0, ra: 1, ad: 1 -- Rcode: NOERROR -- Opcode: QUERY -- Question section lupa.cz. IN AAAA -- Answer section lupa.cz. 600 IN AAAA 2001:67c:68::7b lupa.cz. 600 IN RRSIG AAAA 5 2 600 20121022235305 20111023235305 8130 lupa.cz. wFdVqKCEh4Nmac3v5K9y6HT+aIBAtF4Q9QIqHjlAl/ljp4m5TKkgKCF083zFTMh0LqfwdODfQdSNTKAwO55hyw== -- Authority section lupa.cz. 600 IN NS ns.iinfo.cz. lupa.cz. 600 IN NS ns6.adminit.cz. lupa.cz. 600 IN RRSIG NS 5 2 600 20121022235305 20111023235305 8130 lupa.cz. SpqkpBlK1dzrfACHh3yfUp01Vr/w9qzVYQms4RDXNQZW1Hwr5WYMHIuGrFEgOOrjyg1vB01HENXJf4i2ISx51g== -- Additional section Other implementation notes: - some checks like whether private address is resolved are missing (also a whitelist of allowed RR-types might be implemented) - in the SOCKS5 request, RR-type is hacked onto port number - in SOCKS5 reply, high byte of length is hacked onto SOCKS5 reserved byte - libunbound supports async resolving, for now synchronous is used - there are more details, grep FIXDNS in code - Makefile.am's have -lldns and -lunbound hardwired - new code may not be pretty at some places (getting to know Tor code) Also, this seems to be a bug in relay.c:connection_edge_process_relay_cell_not_open(), the RELAY_COMMAND_RESOLVED case: answer_len = cell->payload[RELAY_HEADER_SIZE+1]; if (rh->length < 2 || answer_len+2>rh->length) {...} Payload is accessed before checking bounds. Ondrej

5 12

Improving the tests
by Esteban Manchado Velázquez 01 Feb '12

01 Feb '12

Hey guys, I wanted to try and help a bit, but I'm not exactly a C wizard or know much about networking code. However, I am an experienced developer, do understand C and have quite a bit of experience with automated testing. Luckily, according to https://www.torproject.org/getinvolved/volunteer.html.en#unitTesting, it seems you guys could use someone spending some time with the tests :-) I'm sure it's going to take me a while to get my head around the code and the tests, but I can give it a shot and see what happens. How do I get started? Any suggestions? -- Esteban

3 2

Fwd: Tor Transports
by K. Macy 30 Jan '12

30 Jan '12

I felt it premature to publicly discuss using my user level network stack as the basis for a tor transport given the number of potential candidates and the issues that I raise below. However, Sebastian felt strongly that it belongs on tor-dev. Cheers ---------- Forwarded message ---------- From: K. Macy <kmacy(a)freebsd.org> Date: Sat, Jan 21, 2012 at 3:05 PM Subject: Re: Tor Transports On Fri, Jan 20, 2012 at 11:35 PM, Steven Murdoch <Steven.Murdoch(a)cl.cam.ac.uk> wrote: > Hi All, > > One hop-by-hop transport protocol we will likely be considering for an alternative Tor transport is TCP, and Kip Macy (a FreeBSD developer, Cc'd) has been working on porting the FreeBSD network stack to userspace, with the Tor use-case in mind. Unlike many other attempts though, maintainability has been a primary concern, so we should be able to keep in sync with the FreeBSD stack with manageable effort. > > Another advantage of this approach is that we will get IPSec for free, which could be very useful if we decide DTLS is not the way to go. > > The FreeBSD network stack is extremely well tested, so we are in a good position from that respect. One downside is that the code size might be large (unless we can find a way to do some clever link-time optimization away of dead code). > > His code is here: http://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_trunk_libple… It obviously also supports SCTP to whatever extent that FreeBSD does. The author of the RFCs and of the reference SCTP stack on all operating systems except Linux is a FreeBSD committer. Another reason why I chose to take this approach is you get all of the kernel firewall bits "for free." Thus one could envision supporting transparent proxying in the application itself to allow for transparent Tor usage in an OS independent manner. I have a few additional comments to add to set expectations appropriately. 1) I have a prototype "safe" BPF API whereby an unprivileged application can only receive and send packets on a single or pre-specified set of IP addresses and only advertise its private stack's MAC address. Without this functionality one needs to either layer the stack on top of kernel UDP (perfectly reasonable approach, just requires writing another simple virtual NIC driver) or running as root, whereby plebeian networking becomes a misnomer - a patrician poseur as it were. Having even such a simple kernel module goes against the grain of Tor conventions of not doing anything as root (although configuring things like transparent proxying require a certain amount of futzing as root). 2) The libc shim is written with the idea that it overrides the relevant libc symbols by means of LD_PRELOAD. The library differentiates between "kernel descriptors" for files, unix sockets, or anything outside the scope of the network stack and "user descriptors". For example, when a kernel descriptor is passed to write() libplebnet will call _write() with the arguments and the call should functional as it normally does. 3) At this instant libplebnet does not support localhost communication over TCP/UDP. I believe that the most efficient way of supporting this would be by means of directing those packets to a tap device. 3) Without a (most likely) substantial amount of work to share user level network state across address spaces, the apache style (pre-)forked process with shared accept socket does not work. I have not given it any thought as I don't see a use case for it. 4) Stack configuration was, to my surprise at least, the biggest hurdle. The UNIX APIs for configuring network stack state are anything but user friendly. To enable continued use of the standard tools (ifconfig, route, arp, etc) I wrote a separate library called libplebconf which one would LD_PRELOAD with the pid of the the process to be configured set as an environment variable. At startup libplebnet creates a thread which listens on a unix socket at "/tmp/<pid>" and accepts as messages serialized system calls to the various configuration calls that the aforementioned programs use. To simplify things a bit I've added an additional environment variable with the path to an rc.conf which gets executed at startup to configure the process using libplebnet's ip and route. Most of this will be moot in the event that you choose to cut out layer 3 and interface directly between your L4 of choice and DTLS. I haven't given any thought to how to eliminate this complexity in the event that you choose to use FreeBSD's IPSEC. To avoid boring most readers I have kept the discussion rather superficial. Nonetheless, I hope that this missive clarifies matters more than it confuses them. Cheers, Kip

3 3