- tor-dev - lists.torproject.org

Software Testing
by Lachlan Schahinger 20 May '14

20 May '14

Hello, For a University Project we have been asked to test software, I personally would like to test parts of the TOR project via methods of unit testing and/or fuzz testing. I was wondering if there are any specific areas of the software that need testing that may present results? Thanks,Lachy

1 0

Code review request for bug #9701
by michael＠schloh.com 18 May '14

18 May '14

Hello list, If anybody's feeling particularly friendly, then it would be nice of you to do the favour of reviewing the proposed solution to bug #9701: https://trac.torproject.org/projects/tor/ticket/9701 It relates to clipboard turds of the Tor Browser in violation of the premise of disk avoidance by design. The code in question is attached to the bug report. Georg (GK) has signalled interest, in case you want to coordinate. Thanks in advance! Cheers, Michael

3 5

Metrics tarballs now available as .tar.xz rather than .tar.bz2
by Karsten Loesing 17 May '14

17 May '14

Hello all, we switched the compression format for metrics tarballs. They are now available as .tar.xz (compressed with `xz -9`), with the previous format being .tar.bz2 (compressed with `bzip2 -1`). The effect is that the total size of metrics tarballs shrinks from 212G to 33G. The savings in disk space and bandwidth were too tempting, even though compression and decompression are going to cost some more CPU and memory. The data page now contains links to .tar.xz tarballs: https://metrics.torproject.org/data.html However, the .tar.bz2 tarballs will still be provided for another two months until July 17, 2014. This includes already existing and newly created tarballs. All the best, Karsten

2 1

Cute Otter == Tahoe-LAFS + Tor?
by David Stainton 16 May '14

16 May '14

Hi, What is going on with that cute otter hidden service publishing project? What do people think about having it use the Tahoe-LAFS Onion Grid and lafs-rpg instead of telling users to run their own webservers? Tahoe-LAFS could help to greatly increase the security and censorship resistance of the data being published. If the people involved with this were interested in using Tahoe-LAFS as the data store then I would be more than happy to help out with this. (I don't do any web development at all) Sincerely, David

3 3

Collecting data to demonstrate TCP ISN-based port knocking
by Christian Grothoff 15 May '14

15 May '14

Hi all, some of you might remember a project called "Knock", which implements a variant of port-knocking in the Linux kernel that can be used to check the authenticity of arbitrary TCP connections and even can do integrity checking of the TCP payload by using a pre-shared key. Knock started as a student project which was presented during the Tor developer meeting at Technische Universität München last July. This was also where Jake added his two cents to help the project to move on. We still hope that Knock will be eventually useful for Tor (think: bridges), but could use your help to collect data to help convince the Linux people to adopt the latest patch. As Knock uses two fields in the TCP header in order to hide information and we explicitly want to be compatible with machines sitting in typical home networks, we need to make sure that this information doesn't get corrupted by the majority of NAT boxes out there. We thus created a program which tests if Knock would work in your environment. It would be great if some of you were able to execute the program on your machines in order to help us to get an estimation of if Knock one day could be used in a large scale. You can find sources, binaries and a more elaborate description here: https://gnunet.org/knock_nat_tester Technical details about Knock and a (somewhat outdated) research paper as well as kernel patches are provided here: https://gnunet.org/knock Best, Julian & Christian

1 0

Collecting data to demonstrate TCP ISN-based port knocking
by Julian Kirsch 14 May '14

14 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, some of you might remember a project called "Knock", which implements a variant of port-knocking in the Linux kernel that can be used to check the authenticity of arbitrary TCP connections and even can do integrity checking of the TCP payload by using a pre-shared key. Knock started as a student project which was presented during the Tor developer meeting at Technische Universität München last July. This was also where Jake added his two cents to help the project to move on. We still hope that Knock will be eventually useful for Tor (think: bridges), but could use your help to collect data to help convince the Linux people to adopt the latest patch. As Knock uses two fields in the TCP header in order to hide information and we explicitly want to be compatible with machines sitting in typical home networks, we need to make sure that this information doesn't get corrupted by the majority of NAT boxes out there. We thus created a program which tests if Knock would work in your environment. It would be great if some of you were able to execute the program on your machines in order to help us to get an estimation of if Knock one day could be used in a large scale. You can find sources, binaries and a more elaborate description here: https://gnunet.org/knock_nat_tester Technical details about Knock and a (somewhat outdated) research paper as well as kernel patches are provided here: https://gnunet.org/knock Best, Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTc+ytAAoJENwkOWttRRA4X/MH/3rDq/szoRTxQDNa8TlBQqNv 3Lcsze55XTpaYY2k9gwK5lKUXar4Ngy6v4i+SOjSrC/gZur5j/g/8LhKy5XdvHdl zXXV2+3ubkK+lWzOq0JP3rJ8lKDAW3Lor0EnVEmZv45+fpgQIbyTKvmEUaiU0l5l A10wDsXjvWTApl+S52pga2qK0g397hn+Y99843PRl8KSxpFDP0t4vTBYBZmLYbMT o7rfoe5BiUtogAgvLdlJ4GlQUrHiH4s6QyQb5/obcGBaN1V8ydkjH0pw6yHR4PTD D5IB7ZYadwi+9k1UyQbAwTCs9+6omiPzN0ugeTdcffzQio2eZUzPOQPyS9vRPwM= =gXcK -----END PGP SIGNATURE-----

1 0

Torsocks 2.x status report
by David Goulet 14 May '14

14 May '14

Hi everyone! Took me a while to do it but there it is! For those not following torsocks development, this is a status report of the project. As of April 4th 2014, the release candidate 7 was released. With that release, the main code is now on torproject.org which is now the official upstream of the project. https://gitweb.torproject.org/torsocks.git My Github repository[1] is now a mirror and all tickets from the tracker have been moved to trac.torproject.org. We are still looking for some more Signed-off or/and Acked-by volunteers that want to have a look at the code. With that, 2.0 stable will be released and from there we'll start adding features! :) Thanks to intrigeri and Lunar, you can find the new version in Debian experimental by now. https://packages.debian.org/experimental/torsocks I plan to update the Tor wiki[2][3] with that new version, create a FAQ and a blog post explaining the Why/How of torsocks 2.0. Finally, the old page should be close soon (hopefully) thus moving everything back to torproject.org. https://code.google.com/p/torsocks/ That's about it, again please test and review it to help out :). Cheers! David [1] https://github.com/dgoulet/torsocks [2] https://trac.torproject.org/projects/tor/wiki/doc/torsocks [3] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO

1 0

[PATCH] torspec: fix typos
by Martin Kepplinger 14 May '14

14 May '14

2 1

Hidden Service Scaling
by Christopher Baines 14 May '14

14 May '14

I have been looking at doing some work on Tor as part of my degree, and more specifically, looking at Hidden Services. One of the issues where I believe I might be able to make some progress, is the Hidden Service Scaling issue as described here [1]. So, before I start trying to implement a prototype, I thought I would set out my ideas here to check they are reasonable (I have also been discussing this a bit on #tor-dev). The goal of this is two fold, to reduce the probability of failure of a hidden service and to increase hidden service scalability. I think what I am planning distils down to two main changes. Firstly, when a OP initialises a hidden service, currently if you start a hidden service using an existing keypair and address, the new OP's introduction points replace the existing introduction points [2]. This does provide some redundancy (if slow), but no load balancing. My current plan is to change this such that if the OP has an existing public/private keypair and address, it would attempt to lookup the existing introduction points (probably over a Tor circuit). If found, it then establishes introduction circuits to those Tor servers. Then comes the second problem, following the above, the introduction point would then disconnect from any other connected OP using the same public key (unsure why as a reason is not given in the rend-spec). This would need to change such that an introduction point can talk to more than one instance of the hidden service. These two changes combined should help with the two goals. Reliability is improved by having multiple OP's providing the service, and having all of these accessible from the introduction points. Scalability is also improved, as you are not limited to one OP (as described above, currently you can also have +1 but only one will receive most of the traffic, and fail over is slow). I am aware that there are several undefined parts of the above description, e.g. how does a introduction point choose what circuit to use? but at the moment I am more interested in the wider picture. It would be good to get some feedback on this. 1: https://blog.torproject.org/blog/hidden-services-need-some-love 2: http://tor.stackexchange.com/questions/13/can-a-hidden-service-be-hosted-by…

11 44

Installing obfsproxy from wheezy-backports
by irregulator＠riseup.net 13 May '14

13 May '14

Hello there, tl;dr obfsproxy from wheezy-backports raises exception about not finding Twisted although Twisted-core is installed. I want to install obfsproxy from wheezy-backports on a wheezy machine. The package currently in wheezy-backports [1] depends on : python (>= 2.7), python (<< 2.8), python-pkg-resources, python-crypto, python-twisted-core (>= 13.2) After installation i get: $ obfsproxy Traceback (most recent call last): File "/usr/bin/obfsproxy", line 5, in <module> from pkg_resources import load_entry_point File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2707, in <module> working_set.require(__requires__) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 686, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 584, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: Twisted obfsproxy explicitly requires twisted: $ cat /usr/lib/python2.7/dist-packages/obfsproxy-0.2.7.egg-info/requires.txt PyCrypto Twisted argparse pyptlib >= 0.0.5 pyyaml But in /usr/lib/python2.7/dist-packages/ there is only: twisted Twisted_Core-13.2.0.egg-info Meaning obfsproxy doesn't seem to find Twisted, cause there is no Twisted*.egg-info in dist-packages/ directory. Interestingly obfsproxy wheezy package from deb.torproject.org [2] depends on : python (>= 2.7), python (<< 2.8), python-pkg-resources, python-crypto, python-twisted, python-pyptlib (>= 0.0.4), python-yaml (The same goes for obfsproxy in debian testing.) Notice it's 'python-twisted' and not 'python-twisted-core'. So the package from deb.torproject ends up installing a Twisted*.egg-info in /dist-packages and obfsproxy does not complain. So i'm wondering, is this a bug? Should i file a debian bug for the debian package in wheezy-backports? Does obfsproxy need all of twisted dependencies or 'python-twisted-core' suffices? If the latter how may we fix the original exception? Cheers, Alex [1]: https://packages.debian.org/wheezy-backports/obfsproxy [2]: https://deb.torproject.org/torproject.org/dists/wheezy/main/binary-amd64/Pa…

2 2