tor-dev September 2013

tor-dev@lists.torproject.org

59 participants
70 discussions

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

torsocks: 0.2.4.17 socksport isolate auth
by grarpamp 06 Sep '13

06 Sep '13

libtorsocks(): Need a password in torsocks.conf or $TORSOCKS_PASSWORD to authenticate with ... : Connection refused To use default torsocks 1.3 you'll need to set socksport noisolatesocksauth or prefersocksnoauth or perhaps configure a user:pass in torsocks beyond the unset default, as hinted above. Not sure if the latter socksport option will prevent isolation or block torsocks again when later setting a user:pass in torsocks. I think there may be a case for adding an environment/conf TORSOCKS_RNDAUTH=[0/1] to torsocks such that it will generate a random user:pass per invocation (ie: parallel) thereby isolating each one. While other unset invocations would ride as default over whichever circuits.

1 0

High load even with 0.2.4.17-rc
by Leo Unglaub 06 Sep '13

06 Sep '13

Hey guys, to fix the load issues on my 5 relays i tryed the suggested development version of tor. But there is not difference at all on the exit relays. They all burn on 99% CPU usage at 23 MB/s bandwidth. Is there something special i have to do in the config to benefit from the new changes mad to quicker peerform the handshakes between the circuits? Thanks and greetings Leo -- Website: http://www.leo-unglaub.net Twitter: http://twitter.com/LeoUnglaub Send with Mozilla Thunderbird on Linux (Debian)

2 1

Re: [tor-dev] Pluggable transport weekly meeting
by vmonmoonshine＠gmail.com 06 Sep '13

06 Sep '13

> From: Yawning Angel <yawning(a)schwanenlied.me> > > Assuming not today (2013/09/16) isn't "soon", the times specified works > for me and I will make an effort to attend. > No, I didn't mean today. I just wanted to send it as soon as found out it hasn't been out. Perhapse it was better to wait few hours. But I would like to get some feedback first. Once we agree on a time (which seems Friday works for most people), I'll send a reminder before the meeting to dev list (hopefully to the correct one). Thanks for the effort ;) Vmon

1 0

[GSoC 2013] Status report - Searchable metrics archive
by Kostas Jakeliunas 06 Sep '13

06 Sep '13

Hello, This status update is less extensive/dramatic compared to the last one, but I'm still happy to report to be slowly moving ahead towards a stable searchable archive system. In short, I've been working on what I said I should work on in the last report, more or less: I should now move on with implementing / extending the Onionoo API, in > particular, working on date range queries, and refining/rewriting the "list > status entries" API point (see below). Need to carefully plan some > things, and always keep an updated API document. (Also need to update and > publish a separate, more detailed specification document.) The searchable metrics backend (encompassing a part of the database and the Onionoo-like API) [2] is still happily chugging along online; quite a few folk ran some queries on it, including myself. I'm in the process of expanding my benchmark.py tool to generate realistic-looking parallel/asynchronous traffic for different kinds of relays and API points; from my limited parallelized benchmarking so far, everything looks good - the bottlenecks are still localized to the individual queries. I should try and generate human-readable more-or-less rigorous benchmarking reports and publish them. I've briefly run the backend on an EC2 instance again, to compare benchmark outputs and average query times. Natural database caching seems to be helping quite a bit for the current online database (at ts.mkj.lt), by which I mean, indexes and some query results get cached via natural usage of the backend/database. I've been tinkering on a simple system to pre-warm indexes upon application start (without the need for any PostgreSQL extensions), for more uniformly distributed query times. Overall though, we seem to be doing OK in regards to actual query times. Made updates to the Onionoo API, but haven't pushed them yet (hoped to do that until this report, but finally learning not to delay); expect them soon (and subsequent updates to the Onionoo API doc [3] as well, once that happens.) I'm now trying to incorporate the most recent Karsten's feedback in regards to API points, parameters and some preliminary simplistic caching. Basically, once the date range parameters are working nicely for all three types of documents currently provided by the API, and once the status entry API point is returning valid-after summaries/ranges in a more intuitive document format, the whole thing will hopefully be able to satisfy actual usefulness criteria to a significant extent. Together with caching, it will hopefully be able to be considered as an almost-proper (smallish, as of now) subset of the Onionoo API/backend. Did some experiments with PostgreSQL's pg_trgm module for full-text search (so that search strings matching only the middle of some descriptor field could work); I realize that's not priority now, but I was curious to see if it would work. Nothing conclusive thus far, unfortunately. Specification document explaining more detailed design and applicable use cases for the Onionoo-like API coming along. I should continue finalizing the Onionoo-like API into a working, non-hacky state; keep the codebase clean and maybe do some cleanup refactoring; continue observing database performance; write more documentation; and if all is well, expand the list of fields contained in the three status documents. Besides all this, - update the database to the latest consensuses and descriptors; - turn on the cronjob for rsync and import of newest archives; - caching; - hopefully later integration with the bandwidth and weights documents in Onionoo proper; - import 2008 year data, etc. These couple of weeks coincide with an (not quite planned for) apartment-moving period, but I *really* hope I have the vast majority of the things mentioned working in a decent state by the end of the next week, to leave ourselves some wiggle space to ensure the resulting system is as stable as possible before the official date for the end of the coding period. I'll probably be available throughout the weekend/s, just in case. Cheers to you all Kostas. [1]: https://lists.torproject.org/pipermail/tor-dev/2013-August/005310.html [2]: https://lists.torproject.org/pipermail/tor-dev/2013-August/005311.html [3]: https://github.com/wfn/torsearch/blob/master/docs/onionoo_api.md

1 0

IRC meeting to discuss sponsor F progress on Tue September 3, 18:00 to 19:00 UTC in #tor-dev
by Karsten Loesing 05 Sep '13

05 Sep '13

Hi all, I'd like to schedule an IRC meeting to discuss what progress we made on sponsor F deliverables in August. Time and place are: Tue September 3, 18:00 to 19:00 UTC in #tor-dev That's in (exactly) 4 1/2 days from now (sorry for the short notice). The time in other timezones is: 11:00 in San Francisco 14:00 in Boston 20:00 in Berlin 21:00 in Athens 23:30 in New Delhi People who should attend are: Roger, Nick, George, David, Ximin, Nathan, Matt, Colin, Andrew, Tom, and anyone else who wants to attend. If your name is on that list and you're working on sponsor F stuff, but the date or time doesn't work for you, please email me your progress and I'll report it for you at the meeting. Thanks, Karsten

3 4

Traffic Obfuscation
by josef.winger＠email.de 05 Sep '13

05 Sep '13

Can a developer please explain to me why something like the following obfuscation of 'torified traffic' is exploitable? Suppose a scenario where a collective of authorities is able to observe large parts of the www. Then observing traffic correlation can unreveal a connection through the network. But why can't we just alter the pattern inside the network, such that there is no correlation between 'incomming' and 'outgoing' data anymore? Suppose I'm connected to a server and there is a lot of traffic between from the server to me. Through the TOR network, of course. Data is encrypted and the exploit measures the raw data stream pattern. But why not change the data stream inside the network? Suppose the server A is outside of the TOR network, i.e. it is not a hidden service. The data stream into our network then is out of our controll. Encrypted or not, we can't change it. Now it flows to node B (exit node) and inside TOR. Then node B streams the data to node C, than node C streams the data to node D and node D exits the stream to me. (simplification) Ok now node B got the data from the 'outside world'. Then B and C first make a handshake to define a shared key for a private encryption protocoll only valid for some time. Now node B does not stream the data to node C, but obfuscates it. That means if there are n packages it transforms them into m packages in some unpredictable way and each new packages gets a small amount of additional random-data. (The point is that the new stream will not look at all like the old one) Only node B nows the way to de-obfuscate this. But B and C did a handshake and using this encryption B shares with C how to de-obfuscate the data. Now C recovers the real data and then does another secret handshake with D. (separated from the shared secret with B of course) Then C obfuscates the data again and only D will know how to recover the original data. This repeats until I recive an obfuscatet stream and my client can recover the original data. ====== The point is, that patterns of the in-stream of the server A aren't correlated to what streams from D to me anymore. Hence an observer isn't able to see correlations anymore. Number, size and pattern of the stream packages are different. Above this one could try to add randomly zero-information streams between the network and its clients. That way an observer can't even be sure if a client recieves information at al... ====== Now can someone please downtalk this approach? best /jo

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev September 2013