tor-dev January 2014

tor-dev@lists.torproject.org

48 participants
51 discussions

GSoC project idea: pluggable transport that hides data in TCP SEQ numbers / UDP SRC ports
by Jacek Wielemborek 10 Jan '14

10 Jan '14

Hi, I recently had an opportunity to watch David Fifield's lightning talk on pluggable transports that he gave on 30C3. I find the topic fascinating and I'm considering an application to your project for the upcoming Google Summer of Code. My idea is a bit complicated - I'd like to create a pluggable transport that hides data in TCP sequence number gaps or UDP source port numbers. I don't yet have all details thought over, but the way I imagine it right now, the user would have to establish a TCP or UDP connection to the relay. The connection could be completely bogus, though it'd be useful if a lot of data was sent over it. After connecting, the client sends to the server a message with a random RSA key steganographically hidden in the TCP sequence numbers. If the server replies the same way with an RSA-encrypted AES key, the rest of the hidden transmission goes encrypted with it. Since the SEQ number gaps are meant to be random anyway, I believe that this could be very hard to detect. Obviously, this is a very difficult project. I'd like to point out that I already have some experience in both GSoC (worked for Nmap Project last summer, David Fifield was my mentor) and C programming. I imagine that I'd need to create some kernel-to-userspace interface that would let me do the packet manipulation - I'd probably start my research by looking at how OpenVPN implements this kind of stuff as it supports all major platforms. The main question is - would you be interested in mentoring such a project during the upcoming summer? Yours, Jacek Wielemborek

5 4

"Sniper attack" paper by Rob Jansen, Florian Tschorsch, Aaron Johnson, and Björn Scheuermann
by Nick Mathewson 09 Jan '14

09 Jan '14

Hi, all! I see that the NDSS programme is now online: http://www.internetsociety.org/ndss2014/programme One of the papers describes a neat set of attacks described in this paper where an adversary can try to track users by DoSing nodes by running those nodes out of memory. The memory DoS attack from this paper are fixed, thanks to advice from the paper's authors, in Tor 0.2.4.x and later, and we're working on improvements to the rest of our memory management as well. Rob Jansen tells me he's working on a blog post to explain the paper and its results in more detail. You can read it online at: http://www-users.cs.umn.edu/~jansen/papers/sniper-ndss2014.pdf And since there's always somebody too hasty to read past the title, I'll quote the footnote on the first page: "We disclosed our attack to The Tor Project [6] in February 2013. We have worked with them to develop and deploy a short term defense [17], and continue to work with them in developing long term solutions [32]. As a result, Tor is no longer vulnerable since version 0.2.4.14-alpha." best wishes, -- Nick

1 0

Another helping hand
by David Murray 08 Jan '14

08 Jan '14

Hi All, I'd like to volunteer time to the tor project. I can program in C and python with a modest to reasonable degree of competence. I'm not hugely familiar with the Tor codebase, so I thought that writing tests would be a good place to start. Is there any C or Python sub-project that would like someone to write some tests? David

2 2

Re: [tor-dev] [tor-reports] boklm's report for December 2013
by Karsten Loesing 07 Jan '14

07 Jan '14

[Replying on tor-dev@, because I think tor-reports@ is not meant for discussions.] On 1/7/14 12:43 AM, Nicolas Vigier wrote: > - continued to review current status of automation in tor project, and > needs: > https://people.torproject.org/~boklm/automation/tor-automation-review.html > > [...] > > - wrote some proposals for things to do in automation in coming months: > https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… Hi Nicolas, these two documents look like something you have put a lot of work into and that you're still working on. Putting them on people.tpo has a few (major, IMHO) disadvantages: nobody will learn about these documents unless they know the exact URL, nobody will be notified when they change (and therefore see that you're working hard on them), there's no history, and when you delete them (by mistake) they're gone forever. How about moving these two documents to the wiki? Possible URLs could be https://trac.torproject.org/projects/tor/wiki/doc/automation/review and https://trac.torproject.org/projects/tor/wiki/doc/automation/proposals. You could mention at the beginning that people should talk to you before editing these pages. All the best, Karsten

2 1

fuzzer for tor as a masters project
by Pietro Bempos 07 Jan '14

07 Jan '14

Hello, I was browsing the tor site in order to find an idea for my masters project in security and I came across the following: ---------------------------------------------------------------------- In your project ideas page https://www.torproject.org/getinvolved/volunteer.html.en#torCleanup You have the following : Write a fuzzer for Tor to discover security vulnerabilities. Determine if there are good fuzzing frameworks out there for what we want. Win fame by getting credit when we put out a new release because of you! ------------------------------------------------------------------------------------ I have no experience in fuzzers but I think it would be a very nice topic to learn and on the same time contribute. I see that it is possible to create a private tor network for testing https://www.torproject.org/docs/faq#PrivateTorNetwork And maybe use the command line options to have as one point of input https://www.torproject.org/docs/tor-manual.html.en Bassically I send this email for 2 reasons: 1) To see if there are ways that you guys can help me with this on the future and 2) To give me any starting tips mostly related to what type of data that would be good for testing, any other input places from where data can be fed and generally any kind of usefull info related to this. Thanks a lot and have a nice day Pietro.

2 1

Small FTE question
by George Kadianakis 04 Jan '14

04 Jan '14

Hello Kevin, I saw your recent changes to the FTE codebase. The code looks nice! I then tried to test it, but I got a bit confused by the CLI. I wanted to try the good ol' ncat test, where I put FTE in the middle, an ncat listener on the server side, and an ncat client on the client side, and throw bytes around. How would I do that with the FTE CLI? I looked at https://fteproxy.org/docs/0.2/fteproxy.html but I'm not sure how to use the server_port and client_port switches properly. Can I configure the client-side to push data to a specific destination, or is it always a SOCKS listener? Also, is there a way to make fteproxy increase its logging verbosity? Thank you!

2 3

CellStatistics circuit distribution scale could perhaps use adjustment
by starlight＠binnacle.cx 04 Jan '14

04 Jan '14

Have been running a guard for a couple of months with 'CellStatistics' and noticed that the distribution looks out of whack: cell-stats-end 2013-12-20 18:13:10 (86400 s) cell-processed-cells 1409,9,6,6,6,5,4,3,2,1 cell-queued-cells 0.44,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00 cell-time-in-queue 98,1,1,1,0,13,2,1,1,0 cell-circuits-per-decile 15199 Seems like most of the circuits with significant traffic end up in the first bucket and the remaining nine buckets are of little significance. I'm fairly certain that a relative handful of circuits account for 99.9% of the cell traffic with cell-counts in the tens-to-hundreds of thousands. Most of that bot traffic I suppose. Perhaps a log-scaled "loudness" breakdown would make sense? Nothing pressing here, just an observation and a thought.

2 1

TBB 3.5 build failure
by Steve Snyder 02 Jan '14

02 Jan '14

Attempting to build tbb-3.5.1-build1, and failing. See below for failure. I am building on a fully-updated Ubuntu v12.04LTS/x86_64 system. I am using the USE_LXC method because KVM won't work in this VMware VM. On my first attempt I did a "make all". That didn't work, so I tried "./mkbundle-linux.sh" (all I really care about is a Linux/x86_64 build) and got the same error at what seems the same point in the build process. This problem isn't listed in the "Known Issues and Quirks" section of the doc. Can anyone advise me on how to fix this problem? Thanks. ----------------------- 2013-12-28 20:08:35,138 INFO : Searching for GRUB installation directory ... found: /boot/grub 2013-12-28 20:08:35,164 INFO : Calling hook: install_kernel 2013-12-28 20:08:59,860 INFO : Done. 2013-12-28 20:09:01,503 INFO : Running depmod. 2013-12-28 20:09:01,595 INFO : update-initramfs: Generating /boot/initrd.img-2.6.32-54-server 2013-12-28 20:09:06,598 INFO : Running postinst hook script /usr/sbin/update-grub. 2013-12-28 20:09:06,735 INFO : Searching for GRUB installation directory ... found: /boot/grub 2013-12-28 20:09:06,835 INFO : Searching for default file ... found: /boot/grub/default 2013-12-28 20:09:06,842 INFO : Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst 2013-12-28 20:09:07,159 INFO : Searching for splash image ... none found, skipping ... 2013-12-28 20:09:07,261 INFO : Found kernel: /boot/vmlinuz-2.6.32-54-server 2013-12-28 20:09:07,536 INFO : Replacing config file /var/run/grub/menu.lst with new version 2013-12-28 20:09:07,605 INFO : Updating /boot/grub/menu.lst ... done 2013-12-28 20:09:07,611 INFO : 2013-12-28 20:09:07,723 INFO : Calling hook: post_install 2013-12-28 20:09:07,753 INFO : Calling hook: unmount_partitions 2013-12-28 20:09:07,754 INFO : Unmounting target filesystem 2013-12-28 20:09:11,171 INFO : Calling hook: convert 2013-12-28 20:09:11,172 INFO : Converting /tmp/tmptolHOn to qcow2, format base-lucid-amd64/tmptolHOn.qcow2 2013-12-28 20:09:27,192 INFO : Calling hook: fix_ownership 2013-12-28 20:09:27,207 INFO : Calling hook: deploy 2013-12-28 20:09:27,208 INFO : Calling hook: fix_ownership Extracting partition for lxc [sudo] password for steve: lxc-start: No such file or directory - failed to get real path for '/home/steve/buildtbb/gitian-builder/target--' lxc-start: failed to pin the container's rootfs lxc-start: failed to spawn 'gitian' lxc-start: No such file or directory - failed to remove cgroup '/sys/fs/cgroup/cpuset//lxc/gitian' amd64 lucid VM creation failed

2 1

Re: [tor-dev] bridgdb automation
by isis agora lovecruft 02 Jan '14

02 Jan '14

Nicolas Vigier transcribed 1.4K bytes: > Hi, Hey Nicolas, Thanks for all the work you're doing, and my apologies that I hadn't responded to your tor-dev@ call yet. Just in case you haven't seen it, Lunar made a wiki page which has quite a bit of info on it, and I filled in some more on BridgeDB. [0] aabgsn maintained BridgeDB for a year or so, but no longer works on it (though they are more than welcome to do so, if they wish to). sysrqb has been helping me maintain BridgeDB quite a bit (feel free to CC them on BridgeDB topics). > I am currently looking at the status and list of things to be done > regarding automation on tor project. I have been looking at bridgedb : > https://people.torproject.org/~boklm/automation/tor-automation-review.html#… From that page: > Continuous Build > BridgeDB is not currently built and tested by Jenkins. > > However, Isis Lovecruft has a personnal development fork on github that is > built and tested by travis-ci.org: > https://travis-ci.org/isislovecruft/bridgedb/ > > Packaging > BridgeDB does not have packages. It is currently deployed using a Python virtualenv. > To my knowledge, BridgeDB is not currently deployed in a virtualenv (sysrqb was the last to redeploy it). I recently refactored the main loop and scripts so that it *can* run in a virtualenv, and it *should* be run in one, because: 1. We won't need to nag weasel/Sebastian to update/install BridgeDB dependencies. 2. Dependencies will not be installed via sudo. I've been considering creating packages for BridgeDB on PyPI. Pros: * Even if we manually download the bundle, verify the hash, and then install it, this seems potentially easier and less error-prone than checking out a git tag, verifying it, and then building. * Packaging it now reserves the 'bridgedb' Python namespace for our use. Cons: * I don't want to make people think that this thing is a polished distribution system for people who wish to run their own BridgeAuths. If proper packaging is helpful for Jenkins, however, I can easily do so. > Testing > Some unit tests are implemented in lib/bridgedb/Tests.py and can be run with > the command python setup.py test. Actually, the tests in lib/bridgedb/Tests.py are old tests. Running them with `python setup.py test` or `make test` will run them via the Python stdlib unittest module (which doesn't play nicely with Twisted's asynchronicity). See #9865, #9872. [1] [2] There are new tests in lib/bridgedb/test/test_*.py [3] and they can be run with `[sudo] make [re]install && bridgedb test`. I began setting up a system which will run the old lib/bridgedb/Tests.py unittests with Twisted's trial runner (#9873). [4] The old unittests will get run twice, once with removed/deprecated classes and functions which have been taken out of BridgeDB's codebase, and again with new/refactored code; this way, the old unittests function as a (partial) regression test suite. The way I designed it, the removed/deprecated code (various classes/functions before refactoring) will go into lib/bridgedb/test/deprecated.py, and they are `twisted.python.monkey.MonkeyPatch`ed into place for a run of the old unitests in lib/bridgedb/Tests.py. Then, the old unittests are run a second time with the newly refactored code, so that the difference between the two can be clearly seen, and bugs introduced by new code can (hopefully) be caught immediately. > > Proposals > Add BridgeDB build and test to Jenkins Created ticket #10417: BridgeDB should be built and tested on Jenkins https://trac.torproject.org/projects/tor/ticket/10417 > The main thing to be done that I have seen is running the unit tests > with Jenkins when there are new commits. You can let me know if I missed > something important, or if you have other ideas / needs. Needs: 1. We need a lot more unittests, but this is perhaps not a task for volunteers (or, rather, people who aren't very familiar with BridgeDB's code). 2. BridgeDB needs *a lot* more documentation. It had almost none when I started working on it 6 months ago; it has a few bits now. [8] Questions: 1. Does it help if I use tox? [5] [6] 2. If not, I believe you'll need a shell script which Jenkins can use to install BridgeDB in a virtualenv. [7] Or do you need some sort of Maven thing, or both? 3. Is there somewhere I should put that documentation on torproject.org (other than people.tpo/~isis)? [0]: https://trac.torproject.org/projects/tor/wiki/AutomationInventory [1]: https://trac.torproject.org/projects/tor/ticket/9865 [2]: https://trac.torproject.org/projects/tor/ticket/9872 [3]: https://gitweb.torproject.org/user/isis/bridgedb.git/tree/refs/heads/develo… [4]: https://trac.torproject.org/projects/tor/ticket/9873 [5]: http://tox.readthedocs.org/en/latest/ [6]: http://alexgaynor.net/2010/dec/17/getting-most-out-tox/ [7]: http://www.alexconrad.org/2011/10/jenkins-and-python.html [8]: https://para.noid.cat/bridgedb/ Thanks, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

3 5

Damian's Status Report - December 2013
by Damian Johnson 01 Jan '14

01 Jan '14

Hi all, hope you've enjoyed the holidays (and for a few of you CCC)! This December I finally swapped back to focusing on arm in earnest. Good news is that the codebase is rapidly improving [1], the focus for this month being... * Finished overhauling the starter module. * Expanded test coverage as more of arm gets rewritten. * Integrated pyflakes and pep8 with our tests. * Moved user facing strings to the internal configuration. I did this to improve our code, but it could also allow us to add internationalization support to arm in the future if folks want it. [2] Bad news is unfortunately that none of these improvements are user facing, and even by the rosiest estimates arm's next release is still many months off. This December I also finished with my efforts to revise our internal lists. None of the more substantial changes got much support, but this still resulted in some worthwhile improvements... * A wiki with our lists, maintainers, and a brief summary of each... https://trac.torproject.org/projects/tor/wiki/doc/emailLists * We now have a public, documented policy for adding folks to our internal lists. * The tor-assistants list is now a proper subset of tor-internal. * Identified some unused lists we can drop. [3] Cheers! -Damian [1] https://gitweb.torproject.org/arm.git/shortlog/5eebd00?hp=ff27d2a [2] https://gitweb.torproject.org/arm.git/blob/HEAD:/arm/config/strings.cfg [3] https://trac.torproject.org/10463

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev January 2014