- tor-dev - lists.torproject.org

Estimating Traffic Correlation Attack ?
by Salahuddin Pasha 21 Jan '14

21 Jan '14

Hi, I am a student of Saarland University and doing research for a seminar in which we are supposed to do Research-Paper on a certain topic. In my group we want to make the first step towards a tool that could help us predict via which ASNs and IXPs a route will be go. In other words, given two IP addresses (in our case two Tor relays) through which ASNs and IXPs do the expected route or routes go. Such a tool would help estimating whether he would take the risk that some of the ASNs and IXPs could potentially perform a traffic correlation attack. As we want to avoid reinventing the wheel, we wanted to ask you the following questions: 1) Are you aware of an open database or of client-side scripts that could help us predict via which ASNs and IXPs a route will be go, from one given IP address to another given IP address (in our case from one Tor relay to another Tor relay)? 2) Are you aware of any way to map IP addresses to ASNs and IXPs like client-side tools or open-access databases? We already did some research and came across the following sides, providing tools and data concerning our questions: 1. http://www.cs.umd.edu/~nspring/scriptroute.html 2. http://asn.cymru.com/ 3. https://www.robtex.com/ 4. whois + RIPE/APNIC/CMYRU/ARIN to identify address spaces of and to label ASs by iterating over the IPv4 address space, parsing the gathered information and skipping already labeled addresses if NetRange is provided. However, we wanted to ask you whether you are aware of more work concerning our research direction. It seems to us that somebody should already have been interested in such a questions. We would appreciate your help. Best regards, Salahuddin

3 2

Attributes of Current Public Bridges
by Matthew Finkel 21 Jan '14

21 Jan '14

Hi everyone, Over the last few days there were a few questions raised regarding the current status of public bridges and their pluggable transports. I've written a script to gather some data points using the sanitized bridge descriptors and extrainfo documents provided on metrics.tp.o. If anyone is interested in any specific attributes then I can work on providing them. Currently the script provides the number of bridges per distinct OS (Linux, Windows, etc) and per OS version/arch (Windows 7, Windows 8, Linux i386, etc), pluggable transports per OS, number of bridges using a certain versions of Tor, number of bridges that provided contact details (useful or not), and the number of bridges that have their ExtORPort configured (but I'm not sure this is correct). Please let me know what I should add to this list. #10680 is opened for this, as well, so feel free to comment there, too. Thanks! Matt

1 0

Unable to clone gitian-builder repository
by Jacob Garber 20 Jan '14

20 Jan '14

I apologise if this doesn't belong in this list and for my inexperience. I am trying to clone the gitian-builder repository to test out the deterministic builds, but I'm running into an issue: "warning: remote HEAD refers to nonexistent ref, unable to checkout." It creates the gitian-builder directory and a .git directory within, but it is otherwise empty. The command being run is: "git clone https://git.torproject.org/builders/gitian-builder.git" Should I be running a different command?

2 1

Security issue
by tortestprivacy tortestprivacy 20 Jan '14

20 Jan '14

Hello I found a security issue in Tor. With Tor Browser Bundle default settings any web-site can access to local resources by JavaScript and XMLHttpRequest. For example ANY web-site can scan local ports sending a requests to http://127.0.0.1:port and see what port is opened. For example: http://127.0.0.1:80, http://127.0.0.1:8080 and any other ports. If some application listen some port it will be able to accept connections and responce to them. If it will be a local web-server any web-site that you visit can view html-pages on it even if all external incoming connections from Internet to this port are disabled by system firewall and only local connections from 127.0.0.1 are allowed. The decision is turn on ABE (Application Boundaries Enforcer) by default in NoScript Add-On. Now it's disabled by default. After this any web-site can't get access to http://127.0.0.1:port by JavaScript and XMLHttpRequest. This rule will be added in NoScript by default if you turn on ABE: # Prevent Internet sites from requesting LAN resources. Site LOCAL Accept from LOCAL Deny If you have default settings of Tor Browser Bundle, ABE is not turned on. If so you can test what ports are opened on your computer for example here: http://tortestprivacy.url.ph/ Regards

1 0

Allowing NAT for relay/exit nodes - Bootstrap file size
by Juan Berner 20 Jan '14

20 Jan '14

Hi, Im wondering if you have considered this, I haven't seen it anywhere: 1) Allow NAT clients to be TOR relay nodes (even maybe exit nodes) , this would be done using a queue system, possibly in a hidden service but not necessary, where nat relay nodes can query what tor clients want to connect to them and initiate the connection. This would allow more nodes in the TOR network. 2) Reduce the bootstrap file size clients download. An increase in nodes would increase the file, roughly 1.5mb right now, this file could be decreased to 10k if clients would first download a list of hashes that identify each OR, then they choose randomly and retrieve from the directory the information for each of the hashes they choose. This would be a temporary way to start connections while the real bootstrap file is being downloaded. It would only benefit those clients with slow connections. Thanks

3 3

txtorcon 0.9.1
by meejah 20 Jan '14

20 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am pleased to announce that txtorcon v0.9.1 is now available. This release adds quite a few minor bug-fixes, simplifies GeoIP handling (with support for both pre- and post 0.3 pygeoip APIs), a tutorial-style walkthrough, the availability of a "wheel" distribution and uses "twine" to do the uploads (allowing me to actually test the signed tarball and whl files before uploading). Full list of improvements: * put test/ directory at the top level * using http://nedbatchelder.com/code/coverage tool instead of custom script * using coveralls.io and travis-ci.org for test coverage and continuous integration * issue #56: added Circuit.close() and Stream.close() starting from aagbsn's patch * parsing issues with multi-line keyword discovered and resolved * preserve router nicks from long-names if consensus lacks an entry (e.g. bridges) * using https://github.com/dstufft/twine for releases * "Wheel" release now also available * issue #57: "python setup.py develop" now supported * issue #59: if tor_launch() times out, Tor is properly killed (starting with pull-request from Ryman) * experimental docker.io-based tests (for HS listening, and tor_launch() timeouts) * issue #55: pubkey link on readthedocs * issue #63 * clean up GeoIP handling, and support pygeoip both pre and post 0.3 * slightly improve unit-test coverage (now at 97%, 61 lines out of 2031 missing) * added a walkthrough to the documentation sha256 sums for the distribution files: 68e21f719f6541448c0ec8e4a95787a0fe13452dd4086631ffdce79b47134e37 txtorcon-0.9.1.tar.gz b92fb5a767eeb3c3d1ec7626fb992d76c73f068e00e69bda51cdbbfc8868eba7 txtorcon-0.9.1-py27-none-any.whl Note that there are cryptographic signatures in the github repository, linked and hosted on readthedocs as well as via the hidden service. Also note that you did not miss out on 0.9.0; I screwed up the tarball upload to PyPI resulting in a signature mismatch and pypi doesn't let you re-upload a tarball. Thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJS3XBnAAoJEMJgKAMSgGmnkPoH+weZSVm2szTo89Z0LlL3wjdV oUFvypgvlmc6Vetf1jShpO3P31QIVtwpUsRHJPpBYxmcWuZJ2mC/CgVMiQiuHq2g tuUiYeTkwTMSiIgbnPaVqNW1ZJxNCwFulqzwZz6zy55hVCuAr2SArLPhxY4LJLWQ TWGXGbf9hO8+MlF3jYgnfbWxGfrLtmN+eUl/pbuqyicoLbHpIMF2tbdPxl4tn04/ 3yW5IOtQdSzgkI7Fhui0P88H8wyTKaijqKevSTnceSyL5q6YNuCfbm0XMq4pDuCQ ItcOtk0fgFsmfMG3Or3chRdSn+KKXBQVVRFDxafXTnDZFyOyZFxxfQaPfoB07sY= =pjAa -----END PGP SIGNATURE-----

1 0

IRC meeting on Wed, Jan 22, 18:00 UTC to discuss next steps for Weather rewrite
by Karsten Loesing 20 Jan '14

20 Jan '14

Hi devs, we're going to have an IRC meeting to discuss next steps for the Weather rewrite: Wednesday, January 22, at 18:00 UTC in #tor-dev on OFTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140122T18 Everyone's invited to join the discussion. Abhiram, Norbert, and Oliver, who all stated their interest in the Weather rewrite, already indicated that they're going to be there. Possible topics are: briefly introduce ourselves, identify open tasks, assign tasks for the next week, talk about infrastructure that would make us more productive, etc. All that shouldn't take longer than 30--45 minutes. If people want to read up on what this is all about, here are two URLs to start with: https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 https://gitweb.torproject.org/weather.git/blob/HEAD:/doc/design.txt Talk to you on Wednesday! All the best, Karsten

1 0

Torsocks 2.0 RC code review
by David Goulet 19 Jan '14

19 Jan '14

Hi everyone, The torsocks 2.0-rc3 code is getting quite stable in my opinion. There are still some issues but nothing feature critical. https://github.com/dgoulet/torsocks I would really love to have help with code review so it can get accepted as a replacement in the near future. Some of you already gave feedbacks so thanks but now it needs the "seal of approval" from the community :). Here are some things you can start with. This new version is built to be thread safe and provides a good compatibility layer for OSes (right now FreeBSD, NetBSD, Linux and OS X are supported). Considering that, you can direct your attention to this: * Synchronization issues (multi threading, reentrancy, ...) * Security obviously :) * Correctness. This is an "inprocess" library thus it has to be bullet proof so it does not crash the application. In src/lib/, every libc call is in its corresponding file matching the man page name like for instance gethostbyname.c contains all reentrant functions and other version of that family as well (gethostbyname_r, gethostbyname2, etc...). Reviewing them just to make sure they mimick as close as possible the libc behaviour. In src/common, connection.c/.h and onion.c/.h are probably the two interfaces that need review. Connection is the one handling new socket and their state where Onion handles the cookies that are sent back to the client (by default: 127.42.42.x) to map an onion address to that cookie once a connection is established (connect()). Other than that, man pages and documentation are also important. You can send patches via email or/and pull request (github or not), I'm easy for contributions! :) Thanks to all! David

3 6

Dusting off dir-spec.txt
by Karsten Loesing 17 Jan '14

17 Jan '14

[Re-sending, because my first attempt apparently got lost somewhere. Apologies if gets found and this is now a duplicate.] Hi devs, hi dir-spec.txt authors, when I reviewed the open proposals related to the directory protocol, I wondered how to integrate the proposed changes into dir-spec.txt. For example, status opinions (proposal 147) are going to add a new variant of the status data format and a new operation that makes authorities produce and exchange opinions at some point in the voting process. I also thought back when I wrote the patch to add microdescriptors to the spec and remembered that I had a hard time finding the right places to add things. So, here's my question: can we reorder a few things in dir-spec.txt to make it easier to read and easier to extend? (To be clear, I'm happy to submit patches for this, I'm just asking if patches are welcome.) In particular, I'd want to start by making the following changes (if you need a table of contents, here's how I generated mine: `grep -Ev "^ |^$|XXXX" dir-spec.txt | less`): Sections 3 ("Formats produced by directory authorities") and 4 ("Directory server operation") apparently started out by separating passive parts (data formats) from active parts (operations). But then 3.4 ("Assigning flags in a vote") and 3.5 ("Computing a consensus from a set of votes") broke this abstraction. One way to fix this would be to move the two mentioned subsections 3.4 and 3.5 to Section 4. Though, personally I'm not a big fan of the passive-active separation, because the description of passive parts implies a lot about how they're going to be used. And then we end up describing things twice, once implicitly and once explicitly. The better fix, IMHO, would be to turn Section 3 into "Directory authority operation and formats" and Section 4 into "Directory cache operation". Section 3 would specify operations in causal order (not sure if this the right term) and specify data formats together with the operation that generates them: - "creating key certificates", - "accepting router descriptors and extra-info documents", - "computing microdescriptors", - "exchanging votes", - "downloading missing certificates", - "downloading router descriptors and extra-info documents", - "computing the consensus", - "computing consensus flavors", - "exchanging detached signatures", and - "publishing the signed consensus". Section 4 would then only contain the subsections from the current Section 4 that are relevant for caches. In cases where cache operations are equivalent or similar to authority operations, there would be a simple reference to the earlier section. Also on the top-level of sections, I'd want to merge Sections 5 ("Client operation: downloading information") and 6 ("Using directory information") into a single section "Client operation". Would you accept patches making these changes? All the best, Karsten

3 12

Re: [tor-dev] Projects to combat/defeat data correlation
by Ximin Luo 17 Jan '14

17 Jan '14

> I imagine the anonymity set would be much smaller for these combined > transports... fewer people using them. In my understanding, the anonymity set doesn't apply to use of PTs since this is only at the entry side. The exit side does not know[1] what PT the originator is using, so is unable to use that information to de-anonymise. [1] at least, in theory should not know, perhaps someone can check there are no side-channels? would be pretty scary if exit could work out that originator is using PTs.

3 2