- tor-dev - lists.torproject.org

[GSoC] BridgeDB Twitter Distributor report
by Kostas Jakeliunas 11 Aug '14

11 Aug '14

Hi all, preferring existing code over shiny code and being mad late, I * (re)wrote a simple but working churn control mechanism[1], which uses * a general persistable storage system: * in particular, the bot now has a central storage controller which takes care of storage handlers which, in turn, may be of different varieties. Each variety knows how to handle its own kind of storage containers (simple objects with data as attributes). Some of them may be persistable, others necessarily ephemeral (wipe data on close); * right now we only make use of simple pickle-dump-to-file-and-gzip persistable storage; we use it for churn control and for challenge responses; everything is self-contained so to speak; * we hash the user twitter handles (unique usernames / screen names) and round up bridges-last-given-at timestamps; * we handle bot shutdown by catching the appropriate signal (then properly closing down the twitter stream listener and asking the storage controller to close down the handlers); * we use the storage system in the core bot via a general "bot state" object (which is itself oblivious to how storage is actually implemented); * wrote a simple and generic challenge-response system[2] (which makes use of the persistent storage); * instead of doing something very smart, we use a general CR system which takes care of particular challenge-responses; the general CR is usable as-is; the particular CR objects can be easily subclassed (and that's what we do now); * the current mock/bogus CR system that is in place (for testing etc.) is a naive text-based question-answer CR, which asks the users to add the number of characters in their twitter username to a given verbal/English-word number; * I should now finish up with ``BridgeRequest``s, which are the proper way to handle bridge requests in the bot while doing challenge-responses (the current interaction between the core bot and the CR system will lead / has been leading nowhere); * also, there's a question to be had whether the cached (and hashed) answers to CRs should be persisted to storage (if bot gets shutdown while some challenges are pending) in the first place. I've been unable to find[3] or to come up with a concept of a user-friendly *text-based* CR that would stand against any kind of thief who is able to create lots of Twitter users and to write twenty-line scripts solving any text-based challenges/questions presented. Either it will to be a difficult problem that will be easier solved by a computer than by a human (hence unfeasible general-UX-wise), or it will be so "symmetrical" in the sense that one only has to view the source (if even that) to come up with a script trivially solving the challenge presented. Hence I've been slowly moving on with the captcha-over-twitter-direct-messages idea, which is not pretty, but which would at least ensure that we don't give up bridges more easily than in, say, the current IPDistributor. [1]: https://github.com/wfn/twidibot/compare/master...churn_rewrite [2]: https://github.com/wfn/twidibot/compare/churn_rewrite...simple_cr2 [3] it's quite hard to find anything of use in the "chatroom problem" / "text-based challenge response" area. Basically, it would be great to have a "reverse Turing test"[4] that is not about captcha/OCR. I realize this is in itself a very ambitious topic. [4]: some context on early CAPTCHAs / precursors (have been trying to familiarize myself with the general area), http://www2.parc.com/istl/projects/captcha/docs/pessimalprint.pdf -- Kostas. 0x0e5dce45 @ pgp.mit.edu

2 1

A change in the schedule of Pluggable Transport meetings
by George Kadianakis 09 Aug '14

09 Aug '14

tl;dr: From now on, Tor PT meetings happen on Wednesdays. Same time. Next PT meeting: Wednesday 13th of August, at 16:00 UTC. Hello friends, I want to inform you of a schedule change that affects Pluggable Transport meetings. Because of the diverse set of timezones participating in the biweekly PT meetings, we have decided to move the meeting to Wednesdays (instead of Fridays) since for some people the PT meeting occurs during Friday night, which is considered precious social time in some cultures. So the plan is to start having PT meetings on Wednesdays. The time will remain the same for now (16:00 UTC), but it might also change in the future (I will inform you) to make it more convenient for some people. BTW, the changes are effective immediately, which means that our next meeting is on Wednesday, 13th of August 2014, at 16:00. Thanks :)

1 0

New tor relay configuration
by Richard Dennis 09 Aug '14

09 Aug '14

Hi guys, I have recently created a python library that creates a circuit through tor and then can send streams through etc, for the next phase of this project however i require access to a tor relay node to monitor. i have set one up using a raspberry pi, following this tutorial : http://www.instructables.com/id/Raspberry-Pi-Tor-relay/?ALLSTEPS i have three flags already : Running, V2Dir and Valid however when i try to connect to the node i get a destroy cell back after a lengthy wait. the node is Goblin500 and is listed on the consensus, but i am not sure why i am unable to connect to it, Would it be possible for some one to try and create a circuit using this node to see if it works if this does not work does any one know where i have likely gone wrong ? Thanks Rich

1 0

New time for Tor dev meetings: 1330 UTC on Wednesdays
by Nick Mathewson 08 Aug '14

08 Aug '14

Hi, all! Due to time zone changes for a bunch of developers, we're going to have a new time for the weekly core Tor development meetings. Going forward, they will be each Wednesday at 1330 UTC. This is the weekly IRC meeting for people working on the program "tor". (It won't cover all the other programs developed under the Tor umbrella.) As usual, we'll do it on the #tor-dev IRC channel. best wishes, -- Nick Mathewson

1 0

Sybil attack detection (was: Karsten's July 2014)
by Philipp Winter 07 Aug '14

07 Aug '14

On Tue, Aug 05, 2014 at 11:37:45AM +0200, Karsten Loesing wrote: > Started looking into better algorithms to detect Sybil attacks on the > Tor network. Current thinking is that we should define relay similarity > metrics like common IP address prefix length or time between first seen > in a consensus, go throw the consensus archives, and see which relays > look similar but are not defined to be in the same family. Do you already have some code or more details on that? I'm quite interested in this topic and I'm wondering if it wouldn't be best to start with something simple like cosine similarity [0]. We would have to transform a relay descriptor into a numerical vector and then calculate the cosine similarity to other relay vectors. However, this might scale poorly as we would need (n^2)/2 comparisons. We might also want to weigh the vector's elements differently as some of them are easy to control for an attacker (advertised bandwidth, uptime, flags, exit policy) and others require more effort (IP address, ASN, observed bandwidth). Like you mentioned, the key thing to look at might be time, i.e., uptime and derived features such as "total online time in last month" etc. [0] https://en.wikipedia.org/wiki/Cosine_similarity Cheers, Philipp

5 5

Damian's Status Report - July 2014
by Damian Johnson 06 Aug '14

06 Aug '14

For one brief, glorious moment in time I touched code. Really, it happened! House plants can vouch as my witness. Or that is to say, I've coded a lot less than I'd like. Barring a long overdue vacation to Sol Duc this month went toward a lot of random distractions... * Worked with Philipp on overhauling our procedure for flagging bad relays... https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays Philipp's taken the lead here and is doing a great job! While I find this space interesting I'm already spread too thin, so going forward I won't be a co-maintainer for it after all. :( * Looked over Nick Hopper's consensus validation change, adding crypto blob type validation to simplify his work. I now owe him a more thorough code review. (#11045) * Handful of DocTor issues including OOM troubles (#12457), unpleasant amount of noise from consensus parameters (#12708), and a several minor revisions. * Discussed adding a new X- extrainfo descriptor field with Virgil, suggesting revisions and helping him make it conformant with the spec. * System I do development on died a puzzling death. Even after twenty hours investigating I'm still not quite sure what happened. Cleaning out dust, removing the RAID controller, and starting over seems to have done the trick. * GSoC administrative work. We're now less than two weeks from the final evaluations! * Continued overhauling arm but as already mentioned focused on this a lot less on this than I'd like. So little coding makes me grumpy, so like many of you I'm taking a hard look at where my time's evaporating to. Maybe there's something I can change or extricate myself from to better focus. Cheers! -Damian

1 0

Building tbb-4.0a1-build2 fails
by tor-admin 06 Aug '14

06 Aug '14

Hi, when I try to build ttb-4 I run into an error on compiling openssl. I was able to compile previous versions of tbb. Any idea what I am missing for ttb-4? Thanks & regards, torland --- Building utils-linux for lucid i386 --- Stopping target if it is up Making a new image copy Formatting 'target-lucid-i386.qcow2', fmt=qcow2 size=11811160064 backing_file='base-lucid-i386.qcow2' encryption=off cluster_size=65536 Starting target Checking if target is up Preparing build environment Updating apt-get repository (log in var/install.log) Installing additional packages (log in var/install.log) Grabbing package manifest Creating build script (var/build-script) Running build script (log in var/build.log) ./bin/gbuild:21:in `system!': failed to run on-target setarch i386 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError) from ./bin/gbuild:122:in `build_one_configuration' from ./bin/gbuild:224 from ./bin/gbuild:219:in `each' from ./bin/gbuild:219 from ./bin/gbuild:217:in `each' from ./bin/gbuild:217 make: *** [build-alpha] Error 1 from ../../gitian-builder/var/build.log gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -DTERMIO -O3 -fomit- frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 - DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM - DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM - DGHASH_ASM -c -o x86cpuid.o x86cpuid.s x86cpuid.s: Assembler messages: x86cpuid.s:8: Error: invalid instruction suffix for `push' x86cpuid.s:9: Error: invalid instruction suffix for `push' x86cpuid.s:10: Error: invalid instruction suffix for `push' x86cpuid.s:11: Error: invalid instruction suffix for `push' x86cpuid.s:13: Error: invalid instruction suffix for `pushf' x86cpuid.s:14: Error: invalid instruction suffix for `pop' x86cpuid.s:17: Error: invalid instruction suffix for `push' x86cpuid.s:18: Error: invalid instruction suffix for `popf' x86cpuid.s:19: Error: invalid instruction suffix for `pushf' x86cpuid.s:20: Error: invalid instruction suffix for `pop' x86cpuid.s:130: Error: invalid instruction suffix for `pop' x86cpuid.s:131: Error: invalid instruction suffix for `pop' x86cpuid.s:132: Error: invalid instruction suffix for `pop' x86cpuid.s:133: Error: invalid instruction suffix for `pop' x86cpuid.s:145: Error: invalid instruction suffix for `pop' x86cpuid.s:147: Error: relocated field and relocation type differ in signedness x86cpuid.s:161: Error: invalid instruction suffix for `pop' x86cpuid.s:163: Error: relocated field and relocation type differ in signedness x86cpuid.s:169: Error: invalid instruction suffix for `pushf' x86cpuid.s:170: Error: invalid instruction suffix for `pop' x86cpuid.s:174: Error: invalid instruction suffix for `push' x86cpuid.s:175: Error: invalid instruction suffix for `push' x86cpuid.s:192: Error: invalid instruction suffix for `pushf' x86cpuid.s:193: Error: invalid instruction suffix for `pop' x86cpuid.s:223: Error: invalid instruction suffix for `pop' x86cpuid.s:225: Error: relocated field and relocation type differ in signedness x86cpuid.s:253: Error: invalid instruction suffix for `push' x86cpuid.s:262: Error: invalid instruction suffix for `pop' x86cpuid.s:270: Error: invalid instruction suffix for `push' x86cpuid.s:289: Error: invalid instruction suffix for `pop'

2 2

3.6.3-meek-2 bundles that can use the Amazon CloudFront CDN
by David Fifield 05 Aug '14

05 Aug '14

I made some test meek bundles that are capable of using the Amazon CloudFront CDN as a backend, in addition to Google App Engine that was supported before. https://people.torproject.org/~dcf/pt-bundle/3.6.3-meek-2/ https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront To test it, go to the pluggable transport screen, and choose "meek-amazon" from the selection box. meek is a pluggable transports that hides the true destination of your communication (a Tor bridge) by hiding it behind a different domain name. When you select meek-amazon from the list, your traffic will appear to a censor to be going to the domain a0.awsstatic.com, but will actually be going to a Tor bridge on cloudfront.net. I signed up for the Amazon Web Services free tier, which limits use to 50 GB and 2 million HTTP requests per month. Please feel free to use it, but don't depend on it not going away. If it becomes too expensive, we'll have to shut it down until we can find a way to fund operation long-term. (The same goes for App Engine, BTW.) David Fifield

2 3

Using a Tap for Tor's Homebrew recipe to increase confidence in source code authenticity
by Mark Rushakoff 05 Aug '14

05 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I noticed that in the instructions for using Homebrew to install Tor on OSX, the instructions say: > As with any application, you should make sure it came unmodified from the orginal source. Unfortunately, Homebrew does not come with integrated verification for downloads, and anyone could submit a modified Tor! If you use a [Brew Tap](https://github.com/Homebrew/homebrew/wiki/brew-tap), you can have a separate repository (which must be on Github) to track the Tor formula. I believe that if the Tor Project owns that repository, there should be higher confidence that a user installing Tor with Homebrew is installing the intended source code, so long as the user runs `brew install TheTorProject/tor/tor` (instead of just `brew install tor`, which will use the formula in the main Homebrew repo). If this sounds like something the devs desire, I have a tap repository ready to go at https://github.com/mark-rushakoff/homebrew-tor. It includes the tor.rb formula from Homebrew, including its full history. If you fork it to the Tor project (or perhaps Github offers a way for me to transfer ownership), then only someone affiliated with Tor will be able to approve changes to where Homebrew retrieves source code to build Tor. The only extra work in adopting this solution would be finding a way to "deprecate" or redirect the main recipe under Homebrew. I'm not familiar enough with Homebrew to provide direction on that topic, unfortunately. Mark Rushakoff -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v0.6.1-dev Comment: http://openpgpjs.org wsBcBAEBCAAQBQJT4G8NCRDqKXFAudXBCAAAcKYIAJwa99tJQOHxvzn1DyDW DZD+ktBrAg0pZ4FEE58+n2KiH1hzeHGuhLh4mLlsD30CGlDqtjmYKiU7VR/P g9jsQTawqmACI5KQkMkOMkdBKsjKfNwCaLxA7mdSoCHsRcmSKhQH++rg1Bli JiQrHgi9DihNrUku2/Km7leiurBrKED1KK2KAJ9mKnVMF2iRjcV//VQ9Nbtp WJp92mydyTnBEGYQPrt6M57WZjYvrkvYV1/eHYZpulrGcPAcXzDYnHgRhRPL 9bolbQhwyPWU6gvEdLC/+NAlCpN1Lfd/RFCyhksgVr6RT8GJFSdpjg1UVkw4 U/63nEVJR8cF0boBtUWQReQ= =baFT -----END PGP SIGNATURE-----

1 0

carml: tasty treats from your Tor
by meejah 05 Aug '14

05 Aug '14

I've got a first super-alpha release of this thing that's been sitting around for a while. Turns out "sanitize a bit" turns into "refactor some things" and so forth... Anyway, carml does various command-line things with Tor and I thought it might be useful to others (plays nicely with grep, pipes, etc). I would really love feedback on whether the "downloadbundle" command is doing the right thing with certificate-checks. https://github.com/meejah/carml https://carml.readthedocs.org/en/latest/ You can "pip install carml" to try it out. Recommend doing this in a virtualenv: virtualenv trycarml ./trycarml/bin/pip install carml ./trycarml/bin/carml help To check signatures first, instead download the WHL file and associated signature from PyPI, gpg --verify it and then replace "install carml" with "install path/to/.whl" above. Some other things to try: carml downloadbundle --extract --system-keyring echo "hello darkweb" | carml pastebin wait for a new consensus to be published, dump it and exit: carml events --once NEWCONSENSUS Currently, the defaults work with a system Tor (i.e. localhost port 9051). Probably I'll change this to be TBB defaults. To connect to a Tor Browser Bundle instance, do this: carml --connect tcp:localhost:9151 monitor It is written using Twisted and txtorcon. Thanks, meejah

3 4