- tor-dev - lists.torproject.org

gitian replacement proposal
by Nicolas Vigier 25 Jan '14

25 Jan '14

Hello, You can find at this URL a proposal to refactor the tor browser bundle build process, using an other tool to replace gitian: https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… (also added as attached file to this email) I made a prototype to show how it would work: https://github.com/boklm/burps-tor The main improvements in this prototype from the current build process are: - all components are built separately, and include in their output file name the commit hash or version, architecture and OS (if architecture dependant). This allows us to keep previous builds if the commit/version/architecture/OS didn't change. So we can rebuild a bundle very quickly when the browser didn't change. - the gitian replacment has features to download tarballs and verify them with sha256sum or gpg signature, so this can replace the fetch-inputs.sh script. - we can remove the linux/windows/macosx descriptors duplication, and instead use template directives for the parts that differ between those builds (it's still possible to use separate files if they differ completly). - we can define variables based on selected OS. This allows for instance to build python 2.7 when building on Ubuntu Lucid, but avoid building it on other distros which already provide python 2.7. - we can define variables based on "targets" that are set on command line. For instance in the prototype using "--target enable_pt" instructs to include the portable transports (only pyptlib in this prototype) in the bundle. - we can easily switch from building in a VM to building locally - build descriptors can depend on the result of another build descriptor. This remove needs for scripts like mkbundle-*.sh. And I think those improvements should make it easier to rebuild a new bundle automatically when any of the components of the bundle receives a new commit, and then run tests on this bundle. Nicolas

2 3

[Question] Onion router's bandwidth
by hyoseok Lee 23 Jan '14

23 Jan '14

Hi I am junior student in Sungkyunkwan University,South Korea I am studying Tor for my paper In my research, onion router has to report its bandwidth by sending descriptor to authority directory. and then authority directory verifies onion router's bandwidth [Question 1] I hope to know the way how authority directory verifies bandwidth which came from onion router. I was told that authority directory had bandwidth verifying tool called bandwidth scanner. How can I get source code of bandwidth scanner ? [Question 2] I made my own onion router, I configured my onion router's bandwidth 100kB/s But, In updated cached-microdesc-consensus file, My onion router's bandwidth was estimated at 20kB/s and there is "unmeasured=1" It means my onion router's bandwidth had not been estimated. what is difference between measured router and unmeasured router ? Thank you for reading my question

2 1

Projects to combat/defeat data correlation
by Jim Rucker 22 Jan '14

22 Jan '14

There was a story in the news recently of a Harvard student who used Tor to send a bomb threat to Harvard in order to cancel classes so he wouldn't have to take a test. He was apprehended within a day, which puts into question the anonymity of Tor. >From my understanding (please correct me if I'm wrong) Tor has a weakness in that if someone can monitor data going into the relays and going out of the exit nodes then they can defeat the anonymity of tor by correlating the size and number of packets being sent to relays and comparing those that the packets leaving the exit nodes. Are there any projects in Tor being worked in to combat data correlation? For instance, relays the send/recv constant data rates continuously - capping data rates and padding partial or non-packets with random data to maintain the data rates

9 12

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 21 Jan '14

21 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