- tor-dev - lists.torproject.org

a new project: "visionion"
by thomas lörtsch 31 Jan '13

31 Jan '13

Hi everybody, my name is Thomas and a month ago I started working on a project called "visionion" with the goal to visualize Tor network metrics interactively in the browser. I just uploaded a readme describing the thingy and a draft of the database scheme to Github: https://github.com/tomlurge/visionion There's still nothing to look at or play with in the repository and it may well take another week or two until the first prototypes surface, but the dust has settled already a little and concepts and ideas begin to shape. Karsten has been tremendously helpful in the early stages (and I'm sure he'll continue to be). He now suggested to involve more people into the discussion - which hereby I do. I'd be very glad to get your feedback, input, ideas, remarks, scrutiny and I'd like to invite everybody to take a look at the project and comment on any aspect of it - breakdown of the status quo, concept, realisation, or whatsoever! Thanks, Thomas

1 0

User-agent in TBB alpha bundles
by Jamie Nguyen 31 Jan '13

31 Jan '13

I noticed in alpha Linux bundle (2.4.9-alpha-1) that the prefs.js still sets the user-agent as Firefox 10 instead of Firefox 17. I'm not sure which is likely to provide more anonymity, but I just wanted to check whether this was intentional or a slight oversight. Thanks. -- Jamie Nguyen

2 1

Comments on librarifying an Extended ORPort client?
by George Kadianakis 30 Jan '13

30 Jan '13

Hi Nick, I have a question for you. It's not high priority, so feel free to postpone your answer till after the workshop is over. Are you aware of pyptlib? It is a small Python library that does the managed proxy environment-variable/stdout configuration dance, so that people who write pluggable transports don't have to care how the pluggable transport protocol actually works. Another thing I would like transport authors to never learn about is the Extended ORPort. It would be truly great if pyptlib could do the Extended ORPort dance (authentication, send client's IP address, etc.), and after it's completed, let the transport send whatever ORPort data it wants. Unfortunately, I don't know how to do such a thing without influencing a certain networking programming style to the transport author. For example, if I coded the Extended ORPort client in Twisted, the transport author would probably have to use Twisted for the rest of her communication with the Extended ORPort. Similarly, if I coded the Extended ORPort client using the low-level 'socket' module, a transport author who wanted to use Twisted would be in trouble. As a matter of fact, I'm not sure how to do this task without coding separate different Extended ORPort clients for each networking library (one for Twisted, one for 'socket', etc.). But this sounds like too much work. Do you think there is a way to do what I want, or is it a lost cause? #7903 is the relevant ticket. Thanks!

2 1

Re: [tor-dev] All the problems about Stegotorous
by vmonmoonshine＠gmail.com 30 Jan '13

30 Jan '13

I summed up the discussion plus what I had in mind with in 15 tickets that I put on the track. https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… Zack is going to suppliment it with few more steg module concerns. By that time we should have a fairly complete list. > From: Roger Dingledine <arma(a)mit.edu> > We should definitely put a page like that up. Let us know if we can do > anything to help! :) > > (asn or I or others can do the website commit) > > I think we (you? :) should work on a TBB bundle (like the other pluggable > transport bundles people are working on) that ships the simplest most > efficient steg module(s) we've got, so Stegotorus can get some actual > users and start collecting usability/crash/etc bug reports. > > I bet Alexandre et al would be happy to bundle in another thing, with > their current obfsproxy-and-flashproxy bundle. Let me deal the ack bug (https://trac.torproject.org/projects/tor/ticket/8086) in the few following weeks. Then I'll approach Alexandre for bundling and you to put the webpage on. Thanks everybody for your help, Vmon

2 1

Tor QA stress-testing advise
by Lee Fisher 27 Jan '13

27 Jan '13

Hi, Is there any info from current Tor QA use? I am trying to reproduce a Tor bug that causes a Windows-based Tor node to crash (BSOD). The bug needs lots of Tor traffic going through the node for it to crash. I am looking for information on the safest way to diagnose a crashing Tor node, without harming user data or the live Tor overlay. I would prefer to test offline, not using the live Tor overlay, since it may destroy user's data, perhaps harm nearby nodes, and I'd rather not have to deal with cleartext PII issues when studying the dump file. Is there any existing private Tor overlay, perhaps used by some academic research purposes, that I could briefly use for this test? I don't have lab resources available to setup a private Tor network. Is Tor-Lab, or that other similar virtual Tor network tool (Karsten-based?, JTorCtl-based?) up-to-date and usable for current Tor builds? Is there a way to use the live Tor overlay to get some script-generated traffic through a specific node, without letting any real user traffic? Wouldn't that traffic harm adjacent nodes and overlay as well? Any related advice appreciated. Thanks, Lee PS: Thanks to those involved with recent checkins to get MSVC compiler support working again; this will give me working Windows-style symbols in the dump. That is really useful.

1 0

torsocks release pending: towards a release candidate
by Jacob Appelbaum 27 Jan '13

27 Jan '13

Hi, Nick and I have been working on a torsocks release. At this point, I think we're at the point where we want to declare a release candidate which if it has no blockers, we'll likely call it a release. I think we'll call it version 1.3 as that seems to have been the intended version. Here is the git repo for all pending changes: https://gitweb.torproject.org/torsocks.git/shortlog/refs/heads/pending-chan… I'll likely merge this pending-changes branch into master in the next day or three. I've gone through all of the torsocks bugs on the Google code site and closed them out. The few that were sorta valid I've decided to close as unsupported as they were either 0) working for some or 1) totally obscure use cases that we never explicitly wanted to support. I think this also includes all of the pending Debian fixes and thus Debian can use our mainline release without patches after the next release. If anyone is horrified, wants to suggest other patches for inclusion, or has anything else to say (related to Torsocks) please speak up! All the best, Jacob

4 7

On Controller, Tor process structure, client software
by Sebastian G. <bastik.tor> 26 Jan '13

26 Jan '13

Hi, This should be just input, nothing too serious. I'm not interested in any kind of feedback. It's probably not worth it. Feel free to use this thread to refer to changes. I'm also not interested in discussions involving me. Feel free do discuss this anyway. It has to be more detailed and the controller itself has to be more modular as well. I hope the attached txt file came through and looks like it should, where it would not look great when dumped into this message. Good Luck. Regards, Sebastian -- everything evolves into decay

2 2

Twisted-based Tor client performance measurement tool
by Karsten Loesing 25 Jan '13

25 Jan '13

Hi everyone, you probably heard of Torperf [0], the tool that produces our Tor client performance graphs [1]. Torperf is mostly a bunch of scripts and lengthy HOWTOs, so setting it up and keeping it happy is not exactly trivial. The same applies to extending it, e.g., to make downloads using Selenium/Firefox rather than using its own C SOCKS client. I'm pondering a rewrite of Torperf in Twisted. The idea is to have a single Twisted application that is trivial to install and that does the following things: 1) set up local Tor clients, configure them, and register for events; 2) run a local web server to download files from or upload files to; 3) periodically run one or more tests which can be: 3.1) an HTTP GET request over Tor to its own web server, 3.2) an HTTP POST request to measure upload speed, 3.3) a GET or POST request to a locally running hidden service, 3.4) a series of fetches of top 50 Alexa domains using Selenium/Firefox; 3.5) a series of requests to track stream/circ allocations for #5830; 4) store request timestamps and Tor controller events to SQLite; 5) provide results via a RESTful API over its web server. That's a lot, and to make things even more fun, there's a sponsor deadline to have more realistic Torperf measurements by February 28. So, I want to start with 3.4 and minimal versions of 4 and 5. But I want to make sure that the remaining parts can be added later without redesigning everything again. My questions: - Is Twisted the right framework for this? What are the alternatives? - Is there existing code that I should look at before writing new code? - Does anybody want to help out? :) Thanks! Karsten [0] https://gitweb.torproject.org/torperf.git [1] https://metrics.torproject.org/performance.html

7 17

Re: [tor-dev] [tor-talk] Open streams on the fly
by benjaminlincoln＠lavabit.com 23 Jan '13

23 Jan '13

> On Mon, Jan 21, 2013 at 2:56 PM, <benjaminlincoln(a)lavabit.com> wrote: >>>> I see, tor already implements such a flag, ISO_STREAM. >> >> I attached a simple formal proposal for this idea. Please discuss. > > Proposals go to tor-dev, not tor-talk. > > Before you re-send, you should check out the discussion (what there is > of it) on ticket #7553 at > https://trac.torproject.org/projects/tor/ticket/7553 . The major > concern at the time was the performance impact from a large number of > users all activating this option. The discussion on the ticket has > stalled; it would be nice to reboot the discussion on tor-dev and try > to bring it to a conclusion. > > In particular, if people think *this* is a good way to "maintain > separate identities" for something like web browsing, that's an > accidental DOS attack waiting to happen. > > Following Nicks's advice I would like to start a discussion on ticket 7553. https://trac.torproject.org/projects/tor/ticket/7553 I think this feature should be exposed to the user. I refrained from writing "implemented" because this feature is already implemented. Not exposing it to the user will not stop Bad Guy(TM) from using it because it can easily be enabled by a trivial 2-line patch to tor. This will not lead to DOS. Circuits being created is slow for the user. I doubt anyone will enable this for real-time, interactive communication like surfing. It hurts anonymity, too. Cypherpunks patch mentions this. 895 **IsolateStream**;; 896 Don't share circuits at all, i.e. isolate each stream to an individual 897 circuit. (Not suitable for browsing or general use, where it *will hurt 898 your anonymity* due to the noisy request profile. The constant creation 899 of new circuits will also be excruciatingly slow for you and put 900 unnecessary load on the Tor network.) Most protocols, in particular HTTP(S), explicitly request their connections to be kept alive. IsolateStream will not have a real effect on these protocols.

2 1

Simple example in C
by monet＠tormail.org 21 Jan '13

21 Jan '13

Anybody can help me? I search a simple program in C to read information from hiden services in tor. Services is simple perl script. and only tcp

1 0