- tor-dev - lists.torproject.org

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 09 Sep '13

09 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

Damian's Status Report - August 2013
by Damian Johnson 07 Sep '13

07 Sep '13

Hi all, after a month of work I'm pleased to announce that the Stem based replacement for Doctor is now live! https://gitweb.torproject.org/doctor.git https://lists.torproject.org/pipermail/tor-consensus-health/2013-September/ For those who aren't familiar with it, Doctor is a service that pulls hourly consensus information and checks it for a host of issues (directory authority outages, expiring certificates, etc). In the case of a problem it notifies tor-consensus-health@, and we in turn give the authority operator a heads up. The new version of Doctor replaces Karsten's java based counterpart and is part of our ongoing scheme to eventually deprecate Metrics-lib in favor of Stem... https://trac.torproject.org/8252 Other news this month includes... * Arlo Breault added DNSEL exit list parsing to Stem! https://stem.torproject.org/api/descriptor/tordnsel.html https://trac.torproject.org/8255 * Stem now mirrors Tor's hardcoded directory authority information (both required for the stem.descriptor.remote module and handy for scripting)... https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remo… * Added an example of remote descriptor fetching to our tutorials... https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#where-… * FAQ entry describing other controller libraries... https://stem.torproject.org/faq.html#are-there-any-other-controller-librari… * FAQ entry for the various ways of instantiating a Controller... https://stem.torproject.org/faq.html#how-do-i-connect-to-tor * FAQ entry describing python's 'with' keyword (this has been a common point of confusion for new stem users)... https://stem.torproject.org/faq.html#what-is-that-with-keyword-i-keep-seein… * Looked a bit unreliability regarding Tor's DirPort. Unfortunately requests for compressed descriptor data frequently fail with a truncated response, so Doctor is now requesting uncompressed data (bad, but likely better than hammering authorities with retries). https://trac.torproject.org/9379 * Assigned joint copyright of Stem to The Tor Project so it can live on if I get struck by a meteor, swallowed by a dragon, etc. * Support for new Tor capabilities including TRANSPORT_LAUNCHED events and bridge-ip-transports lines in extrainfo descriptors. * Overhauled the layout of arm's codebase so it'll behave like a more proper python module. * Discussed using Stem for Bridgedb with sysrqb and isis. https://trac.torproject.org/9380 * Answered a few controller related questions on Stack Overflow... http://stackoverflow.com/questions/18561778/how-do-i-get-the-ip-address-of-… http://stackoverflow.com/questions/18372615/tors-stem-module-python-failing http://stackoverflow.com/questions/18578908/torctl-errors-out-with-torctl-c… Cheers! -Damian

1 0

I have a project that might interest you. OnionMail
by Liste 07 Sep '13

07 Sep '13

Hi, my name is EPTO. I am the founder of Anopticon Project and tramaci.org http://tramaci.org/anopticon (Map of Video surveillance cameras) http://tramaci.org (This listsmlm(a)tramacci.org is my mail address for mailinglists). I'm building a new project: A mail server for the tor netword to increase the privacy of mail communications. The project is named "OnionMail". OnionMail is a SMTP/POP3 compatible mail hidden server with some extended functions: * Multiple instances of server. (multiple indipendent hidden serivces). * SSL cryptography by default. (STARTTLS) * Encrypted filesystem with asimmetric keys for any user, any log and messages. * Multiple encryption everywhere, RSA + AES + RSA + AES with salt * Support for unicode password * Inhibition of store any message in relay server. (Only direct connection is allowed without multiple connections). Eg.: Client_Of_Sender -> SMTP1 -> SMTP2 <- Sever_Of_receiving * Metadata protection * SMTP Compatibility * AntiSpam, blacklist realtime filters * Decentralized trust system for SSL certificate and public keys, GPG keys, Spam blacklist, etc... * Mailing list support * Anonymous remailer * username(a)address.onion email addresses. Your onion mail ;) * Garbage collector to remove automatically old messages. * GPG Support and optionaly GPG compulsory. * Clock and time zone spoofing. * Bulit in server operations: Add / Remove mail address or mail server in black list. Mailing list Subscribe / Unsubscribe KeyServer Request for anonymous mail address Request of server "rulez". (All via mail message to the server directly "server@ xyz... .onion ") * JAVA Implementation for all platform. * Localhost control port and server API. * Protected server password and keys (optionaly not saved). * Localhost full net use: 127.0.0.1 127.0.0.2 etc... * IP BlackList * onion BlackList * tor connection verifycation. Optional: * SMTP Exit Route/Enter Route with mail alias to connect internet to tor and vice versa. * DNSBL for normal SMTP operations. (not user for .onion address). * Mindless compliant mode: Prevent bad use of DNS, direct internet connection, exit enter node, enable only tor operations. * Etc...... The project is not pubblic at this time. In a short time it will public. (Ver 0.0.1 Beta) I joined to get some advice. I read somewhere that you should contact for projects here. What do you think about OnionMail? Sorry if the message is too long. but the project is big. The slogan is: «In the future, maybe we will implement the anonymous coffee! Today, only OnionMail ;) »

3 2

GSoC Status Report - EvilGenius
by Johannes Fürmann 06 Sep '13

06 Sep '13

Hi *, In the past two weeks, I've been working on EvilGenius. I had some weird problems with vagrant, and in the meantime I switched to Debian, but that is another story. I spent most of my GSoC-time on some seriously weird routing issues, one of which I eventually solved today. I am confident that I will solve the other routing Issues early next week. What is left to do is write documentation. You all have a beautiful weekend! ~johannes

1 0