- tor-dev - lists.torproject.org

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

Re: [tor-dev] Proposal 225: Strawman proposal: commit-and-reveal shared rng
by George Kadianakis 16 Jan '14

16 Jan '14

I'm forwarding a private email by Florian Dold which is related to this discussion. I talked with Florian during CCC and we talked some more over email. Reposting with his permission. Thanks! From: Florian Dold <dold(a)in.tum.de> Date: Sat, 4 Jan 2014 20:45:15 +0100 To: George Kadianakis <desnacked(a)riseup.net> > > Hi! > > I'm afraid there is not much usable information in the slides, it's > just a quick overview of what I'm currently implementing for GNUnet > ... > > However, I do have some comments / ideas for the distributed nonce > generation in Tor. From what I read, most of your current efforts > focus on protocols for distributed *key* generation, which might be > overkill, as your scenario needs less structure --- only a random > value, not a key pair must be generated. > > There's been a lot of theoretical discussion about that in literature > about exactly that, usually under the name "Collective Coin Flipping" > or "Leader Election" (which also must generate a random number), and I > think these ideas are more appropriate for your problem than those > from DKG. > > Let me sketch how their protocols (see [1], [2] and many many more) > work. For simplicity, let's only generate single bit: > > 1. Each player P_i broadcasts a boolean b_i. > 2. The resulting random bit is f(b_1,...,b_n) > > Now, when f = XOR, this corresponds exactly to the protocol we > discussed, which is not secure against adaptive adversaries. However, > when choosing f as the majority function > > f(b_1,...,b_n) = 1 if sum(b_1,...,b_n) > ceil(n/2), 0 otherwise > > it won't be as easy for a single player (or even a small coalition) to > influence the resulting bit (as there's a chance that their choices > don't even influence the final result). > > There are constructions for the function 'f' in literature that are > even more influence-resilient than the majority function. > > > But of course, this is only part of the issue: Problems arise when > players don't broadcast their values correctly. This essentially > boils down to the byzantine consensus problem, and there are various > approaches to this. One of the simplest implementations of this are > based on gradecast [3], a multicast protocol that also gives a > "confidence level" for the correctness of the broadcast. There are > many optimizations of gradecast, including some probablistic > constructions for settings with a large number of players. > > The last paragraph, however, also might apply to distributed key > generation that do *not* use the Fouque-protocol with its complex > zero-knowledge proofs of fair encryption to avoid private channels. > > > Does this help? While still somewhat complex, the collective coin > flipping protocols are probably still less complex than establishing a > distributed key and then doing threshold elgamal, as proposed by > Nicholas Hopper. > > Happy Hacking! > Florian > > [1] http://www.cs.huji.ac.il/~nati/PAPERS/coll_coin_fl.pdf > [2] www.cs.yale.edu/homes/aspnes/papers/stoc97-proceedings.pdf > [3] http://arxiv.org/abs/1007.1049 > > On Sat, Jan 4, 2014 at 6:38 PM, George Kadianakis <desnacked(a)riseup.net> wrote: > > Hey there, > > > > I'm the guy that talked with you about Distributed Key Agreements in CCC. > > We talked about its applications in Tor (we need Distributed Nonce > > Agreement) and attacks on the naive commit-and-reveal method. > > > > I was wondering if your slides or talk is uploaded somewhere on the > > Internet. I found > > https://gnunet.org/content/video-30c3-talk-gnu-name-system but it doesn't > > seem to be the one I was looking for. > > > > Thank you! > > > > [BTW, the relevant Tor ticket is: > > https://trac.torproject.org/projects/tor/ticket/8244 > > and the threshold elgamal idea is here: > > https://lists.torproject.org/pipermail/tor-dev/2013-December/005944.html ] > > > >

2 1

Re: [tor-dev] Projects to combat/defeat data correlation
by Malard Joel 16 Jan '14

16 Jan '14

Sounds like a challenging problem, good luck. In the case of the Harvard exam, the administration may have used some meta data that may not be under your control, listing out all student taking an exam that day, asking teachers for a shortlist of their class jerks and clowns, checking for repeat offenders, finding which ones had downloaded TOR software, asking frat buddies and classmates. Someone willing to send a bomb threat just to avoid an exam may be more likely to brag after the fact, etc. Cheers, Joel ------------------------------ On Wed, Jan 15, 2014 7:16 PM PST Jim Rucker wrote: >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

1 0