- tor-dev - lists.torproject.org

RFC: Lightweight Obfuscated Datagram Protocol (LODP)
by Yawning Angel 13 Sep '13

13 Sep '13

Hello all, Inspired by a conversation with arma, I have been working on designing a UDP based protocol to serve as the bulk data transport for something along the lines of "obfs3, but over UDP". The spec document is approaching the point where I would like to have increased public review before I go and implement it. People who sit in #tor-dev probably have seen various revisions of this draft already. Some notes: * This is heavily inspired by SSU from the i2p project, and Dust by Brandon Wiley. * Ensuring that data gets delivered reliably and in order is outside the scope of this document. Such things are a well researched problem so my reference implementation will likely draw upon an existing protocol instead of reinventing the wheel here. * As far as existing work in this area, the only other protocols that attempt to do similar things are i2p's SSU and Dust. * LODP assumes that there is a shared secret between peers to attempt to thwart active probing attacks. * As part of my evil plans, "secure fingerprinting resistant UDP" is something useful to have. * Open questions/things that are subject to change are tagged with XXX. Questions, comments, feedback appreciated. -- Yawning Angel

1 1

Pluggable transport weekly meeting - Friday Sept 13
by vmonmoonshine＠gmail.com 13 Sep '13

13 Sep '13

Hello pluggable transport devs, As there was no objection to the proposed time, we are going to have our first one today/tomorrow: Friday - Sept 13 CEST: 18:00 BST (Summer GMT): 17:00 UTC: 16:00 EST: 12:00 MNT: 10:00 PST: 9:00 @ #tor-dev on irc.oftc.net And stick to it in future. The format will be scrum-esque. At the beginning we'll ask who likes to participate. Then we ask each participant in some order to give a short update on what they have done last week, what will be doing in the coming week and if they have any questions/problem they want to ask from/share with other developers. We hope to be able to keep it under 30min, so if you find your peer for deeper detailed discussion then you might want to keep the discussion for after the meeting. Thanks! Hopefully See you all, Vmon

1 0

Pluggable transport weekly meeting
by Vmon 13 Sep '13

13 Sep '13

I sent this email quite a while ago and I was surprised that nobody was interested/replied. Today I found out that I had sent it to a wrong address. But here we are, so I'm sending it again. So please reply so we can kick this off soon. Thanks, Vmon ---------- Forwarded message ---------- From: <vmonmoonshine(a)gmail.com> Date: Wed, Aug 21, 2013 at 6:46 AM Subject: Pluggable transport weekly meeting To: tor-dev-request(a)lists.torproject.org Hello Tor devs, Following up on what we came up with in the dev summit ( https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… ), we are going to have weekly 30-minute IRC meeting focusing on pluggable transports. The format (I think) will be scrum-esque that every developer who is working on a pluggable transport will update everybody else about the work they did/are doing on their transport during the week and ask questions if they have any, for example if they got stuck somewhere and they think somebody can help. Preliminary, we decided to have the meeting on Fridays, cause why not, but if you have serious problem with Fridays then we might be able to pick a better day. For the time of the meeting, considering the geographical positions of the current transport developers, we'll probably end up having a CEST evening and PST morning meeting. Having that in mind I suggest: CEST: 18:00 BST (Summer GMT): 17:00 EST: 12:00 MNT: 10:00 PST: 9:00 So if this doesn't work for you, please reply to this email with your alternative proposal. Thanks, Vmon

7 9

Pluggable Transports and rate limiting
by George Kadianakis 11 Sep '13

11 Sep '13

Hey Yawning (and tor-dev), a topic that we will soon need to consider seriously is rate limiting of pluggable transports. For example, Obfsproxy at the moment does not understand rate limiting and will happily read and write as many bytes as needed. After some discussions in IRC and #3587, we decided to add rate-limiting commands to the TransportControlPort -- that's the (unimplemented) real-time sister of ExtendedORPort. You can see the details in the relevant proposal: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/196-transpor… (see RATE_LIMIT command etc.) The idea here was that Tor would monitor its bandwidth usage and order PTs to slow down appropriately. If an accounting limit was hit, Tor would order PTs to stop pushing traffic completely. Does this look like a reasonable way to enforce accounting/rate-limiting policies? How could it be improved? For example, I'm kind of sad about this approach, because it requires little-t-tor to do all the hard work of monitoring bandwidth usage and giving out intelligent rate-limiting orders. For example, how do we rate-limit N pluggable transports to 100 kb/s? Do we allow each pluggable transport to push 100/N kb/s? I don't like that this logic must be implemented in little-t-tor. Also, do the TransportControlPort rate-limiting commands look reasonable? Is the payload of RATE_LIMITED (two integers: bandwidth rate and bandwidth burst) properly designed, or does it need more information? Also also, will this work nicely with transport combos (#7167)?

3 3

Tor Cloud is broken - please help debug?
by Runa A. Sandvik 10 Sep '13

10 Sep '13

Hi everyone, It seems something is wrong with the Tor Cloud [1] instances [2]. My best guess is that the instances are failing to auto-update packages and are left in a state where tor is not running, new packages are not being installed, and the instances are not doing anything useful. I am not able to look into this issue until next week. Does anyone want to poke at it sooner? The best ways to debug this would be: * Set up a Tor Cloud instance (open all the right ports and make sure you have a set of SSH keys for it), connect to it and look through the logs. I'm guessing the package update process is waiting for user input or something similar. * Set up an Ubuntu cloud instance and go through the Tor Cloud setup [3] manually to see when/if something breaks. [1]: https://cloud.torproject.org/ [2]: https://metrics.torproject.org/network.html#cloudbridges [3]: https://gitweb.torproject.org/tor-cloud.git/blob_plain/HEAD:/ec2-prep.sh -- Runa A. Sandvik

1 0

dynamic changes to ORPort set (via controller)
by Zack Weinberg 09 Sep '13

09 Sep '13

Suppose I have a relay (not a client) which starts out with one open ORPort and a local controller. 1) Is there a better way (read "supported in STEM") than using SETCONF to add ORPort lines, to direct this relay to open additional ORPorts? 2) Will adding or removing ORPorts at runtime affect established connections to other ORPorts (those which are open before and after the change)? thanks zw

2 2

Quickly testing TOR using Chutney and Fluxcapacitor
by Marek Majkowski 09 Sep '13

09 Sep '13

Tor ships with some testing facilities (tor/src/test/test), but they are not comprehensive. (I'm aware there's an ongoing effort on improving these tests). To test anything non trivial it is necessary to run a tor node as a part of a tor network. There is another tool called chutney [1] that can be used to set up a small testing Tor network: it generates plenty of torrc configs and spawns a number of Tor servers locally. This is very handy, but it can take a while before the network starts working - the Auth servers need to establish the consensus and do all the things I have no clue about. Here's a simple shell script [2]: - It uses chutney to start a testing tor network. - It waits for it to work by trying to establish a connection to localhost:22. - Finally it tears down the network. Normally it takes around 5 minutes for the network to converge: $ time ./go.sh real 4m8.330s user 0m2.064s sys 0m0.392s Of course, you don't have to set a completely fresh Tor network for every single test, but that's what I often do. I'd be eager to hear how people are reusing chutney networks. In past I wrote this thing called fluxcapacitor [3], it's a tool that speeds up tests. After a few fixes I was able to run chutney on it: $ time /tmp/fluxcapacitor/fluxcapacitor ./go.sh real 0m11.450s user 0m2.340s sys 0m2.120s Running stuff under fluxcapacitor is not deterministic, sometimes it takes 8 seconds, sometimes 15 but it generally works and should go pretty quick. That's it. I thought someone may find it useful. Cheers, Marek [1] https://gitweb.torproject.org/chutney.git [2] https://github.com/majek/dump/blob/master/tor/go.sh [3] https://github.com/majek/fluxcapacitor.git

3 4

[GSOC] Status report - Tor capabilities
by Cristian-Matei Toader 09 Sep '13

09 Sep '13

Hello tor-dev, Not much has happened since the last status report. I have been fixing small issues [1] with the seccomp2 filter and have been working on the change requests from nickm's code review for merging stage 2 of tor sandboxing [2]. I am currently waiting for feedback, which is very likely to be final, and a merge of my work in tor's master branch. After stage 2 is completed, I will move on with stage 3 by dropping privileges in different sections of the tor program, as they no longer become required, in order to create a more restrictive sandbox. [1] https://github.com/cristiantoader/tor-gsoc-capabilities/commits/gsoc-cap-st… [2] https://trac.torproject.org/projects/tor/ticket/9249

1 0

[GSOC 2013] Steganography Browser Extension Status Report
by Hareesan 09 Sep '13

09 Sep '13

Hi all, First of all, let me apologize for being late in sending this report. In last two weeks, I was mostly engaged with code updating and fine tuning the code. I spent time in changing the public key cryptography libraries [1] to support Firefox supported imports. And I'm not completed with this part because I need to spend time in understanding the libraries. Since I'm having exams from this week, I won't be able to work on the project for coming weeks and this will be my last status report regarding my GSOC project. Once my exams over, I will continue working in the project from where I'm pausing now. Up to now I have created the extension for Firefox with the following features, 1. Upload contents from physical files to encryption / decryption. Up to now the contents will be popped as byte data format once the user click on encrypt/decrypt button in the upload menu. 2. Get web content from from web page for encryption/decryption purpose. Once user right click on a web content such as image, html video, html audio and select on encrypt or decrypt option and click on encrypt/decrypt button. the byte data of selected content will be popped. All these byte data popped will be used to further message encryption need in the future development of the project. 3. The code to encrypt message using random number also added and the methods to access the libraries will be displayed in the documentation. 4. In options page, the filter creation and relevant sqlite database access codes are added. It can be tested using the Filters tab in options page. All the codes up to now are reviewed and tested by Sukhbir Singh, and changes are made according to mentor's suggestion and possible bugs are got fixed time to time. Time to time, many suggestions and feedbacks were given by Moritz Bartl as well. Future plans for the continuity of the project. 1. There is a need to add public cryptography libraries to the extension. Up to now, the libraries are selected and added to the repository. But there is a need to change libraries to support Firefox supported import export mechanisms. 2. After fixing these all, the primary part of the project to add Steganography libraries exists. You can find the full source code in public repository[2]. Within the coming weeks, I will complete the documentation in detail. Thank you. [1] http://ats.oka.nu/titaniumcore/js/crypto/readme.txt [2] https://github.com/rharishan/Steganography-Browser -- Hareesan

1 0

Testing flash proxy infrastructure
by David Fifield 08 Sep '13

08 Sep '13

George asked me for tips on testing flash proxy infrastructure. You will need to run a websocket-server (https://gitweb.torproject.org/flashproxy.git/tree/HEAD:/websocket-transport) in front of a relay: ServerTransportPlugin websocket exec /usr/local/bin/websocket-server --port 9901 Or you can just use the public one at 173.255.221.44:9901. Let's say the websocket-server is listening at 127.0.0.1:9901. You follow these instructions to set up your own facilitator. https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/facilitator-how… It's fairly involved, and at the end you have an Apache serving a CGI, plus some local daemons. For your own local testing, you can use a self-signed certificate or even plain HTTP, and you probably don't want to do the email poller because that's a process on its own. In /etc/init.d/facilitator, edit the RELAY variable to point to your chosen websocket-server. Say your facilitator CGI is running at https://facilitator:8000/. You point flashproxy-client to the faciltiator using the -f option. ./flashproxy-client -f https://facilitator:8000/ --external --register-methods=http --unsafe-logging To run flashproxy-client in managed mode from torrc, remove --external. The two rendezvous methods that don't require setting up a lot of stuff are http and url. You can add a client registration like so: ./flashproxy-reg-http -f https://facilitator:8000/ --unsafe-logging ./flashproxy-reg-url -f https://facilitator:8000/ --facilitator-pubkey=reg-daemon.pub 127.0.0.1:9000 With flashproxy-reg-url, you will have to paste the URL it prints out into a browser. flashproxy-client will automatically pass the -f option to its registration helpers. To run a local flash proxy, open a non-Tor browser to embed.html and give it the custom facilitator URL: file:///home/user/flashproxy/proxy/embed.html?debug&facilitator=https://facilitator:8000/&initial_facilitator_poll_interval=0 To bypass the facilitator and connect directly to a client and relay, do this: file:///home/user/flashproxy/proxy/embed.html?debug&client=127.0.0.1:9000&relay=127.0.0.1:9901 David Fifield

1 0