- tor-dev - lists.torproject.org

Damian's Status Report - January 2013
by Damian Johnson 03 Feb '13

03 Feb '13

Hi all. This January I've been integrating feedback from first time stem users and implementing their feature requests. Projects included... * Python 3.x Support Stem now works under both the python 2.x and 3.x series. To use stem with python 3 simply use it when you install... python3 setup.py install This turned out to be a larger project than I had anticipated, taking almost half the month. But it was well worth the effort. https://gitweb.torproject.org/stem.git/commit/3930f1f https://trac.torproject.org/7843 * PEP8 Compliance Ditched most of my odd coding preferences in favor of the standard python style guide. I've integrated both pep8 and pyflakes with our tests to prevent regression. Hopefully this'll make it easier for others to contribute to stem. https://gitweb.torproject.org/stem.git/commit/d29ec4d https://trac.torproject.org/7631 * Arm Codebase Refactoring Prior to being shanghaied into the projects above I sunk quite a bit of time into overhauling arm. Thus far I've dropped around a third of the codebase in favor of similar (but tested!) capabilities in stem. * Descriptor Improvements Got lots of input concerning stem's descriptor module (thanks Karsten!), leading to quite a few improvements... * used feedback from Aaron Johnson to make the descriptor API less confusing * we now support bridge network status documents (https://trac.torproject.org/7938) * added support for '-legacy' authorities (https://trac.torproject.org/7866) * parsing error if network status documents lacked a 'directory-footer' line (https://trac.torproject.org/7932) * empty 'bridge-ip-versions' lines caused problems (https://trac.torproject.org/7967) * we didn't recognize the @type annotation for key certificates (https://trac.torproject.org/7987) * we weren't parsing the new ntor-onion-key lines (caught by sonu, https://trac.torproject.org/7868) * error when ran with pypy (caught by peer) Sean helped quite a bit at the start of the month, but has since been busy with other things. * added a Controller.get_streams() method (https://trac.torproject.org/7859) * tests for the close_stream() method (https://trac.torproject.org/7687) * expanded the Controller's unit tests (https://trac.torproject.org/7874) * fixed type checks (https://trac.torproject.org/7873) * fixed test_reattaching_listeners (https://trac.torproject.org/7872) Cheers! -Damian

1 0

extension works in FF, fails in TBB
by Greg Norcie 01 Feb '13

01 Feb '13

Dear Tor Devs, Hello. My name is Greg Norcie, I'm a PhD student at Indiana University, working on a project focusing on improving Tor usability. This is a follow up to a paper looking at usability issues with the Tor Browser Bundle. (http://petsymposium.org/2012/papers/hotpets12-1-usability.pdf) The research group I'm leading is currently working on tweaking the Tor Browser Bundle to test solutions to the issues we noted in a formal lab study. (Our previous paper simply suggested changes, but did not scientifically validate our suggestions) One issue we noted was people feeling Tor was slow. Now, this is a function of how Tor works - traffic passed through a series of nodes will always have more latency than a direct connection. So we are experimenting with a custom extension that pops up a message to TBB users when a delay is detected, to see if reframing the delay makes users tolerate the latency better. However, we have hit a snag. While in a normal, run of the mill Firefox install w/ the same extensions as the TBB, our extension functions - delays are detected and a pop up box appears. However, when we install our custom extension in the Tor Browser Bundle, it fails to work. We initially thought this might be because our extension was utilizing Javascript, but disabling NoScript doesn't fix thes issue. We're at a bit of a loss as to how to solve this issue, and are reaching out to the Tor developer community to see if anyone might be able to offer some insight as to what could be causing this failure. Our lead developer recently left the project, so we're struggling to get things on track in time for PETS) The extension in question is available at the following URL (password is "cryptoparty" - our uni's MegaUpload clone requires a password for all files): https://www.slashtmp.iu.edu/files/download?FILE=gnorcie%2F1700EHKJOv Any help anyone can provide would be greatly appreciated. (And of course, it goes without saying we will be making our code available to the Tor community) Thanks for reading, have a great day. Sincerely, Greg Norcie PhD Student - Security Informatics Indiana University

1 0

torsocks release pending: towards a release candidate
by Oscar Koeroo 01 Feb '13

01 Feb '13

Hi, I've created trac ticket[1] #8063. The torsocks script has an option "on" which did't work and in the current state I'm curious on which shell it did work :-) The patch is included and only affects the src/torsocks.in file with a oneliner. More details are included on the ticket. Oscar [1]: https://trac.torproject.org/projects/tor/ticket/8063

6 8

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

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

19 Jan '13

>> The implementation of proposal 171 and subsequent release of tor >> 0.2.3.25 >> fills my heart with joy. Yet, as far as I can tell, there is one use >> case >> that is not adequately covered. I would like to open and close Streams >> (TransPort's, DNSPort's and SOCKSPort's) at run-time without interfering >> with other, existing Streams and Circuits. SETCONF does not work here >> because it resets all existing streams. > > I think tor lacks an isolation flag which specifies to isolate each and > every stream, even those going to the same address and port. I see, tor already implements such a flag, ISO_STREAM. /** Isolate based on destination port */ #define ISO_DESTPORT (1u<<0) /** Isolate based on destination address */ ... /** Isolate all streams (Internal only). */ #define ISO_STREAM (1u<<7) diff --git a/src/or/config.c b/src/or/config.c index 90a5dfb..648bfba 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -5929,6 +5929,8 @@ parse_port_config(smartlist_t *out, isoflag = ISO_CLIENTPROTO; } else if (!strcasecmp(elt, "IsolateClientAddr")) { isoflag = ISO_CLIENTADDR; + } else if (!strcasecmp(elt, "IsolateStream")) { + isoflag = ISO_STREAM; } else { log_warn(LD_CONFIG, "Unrecognized %sPort option '%s'", portname, escaped(elt_orig)); This looks like a reasonable addition to me - an addition that could be backported to 0.2.3.x.

1 1

Affect of Proposal 207 on user metrics
by Abel Luck 18 Jan '13

18 Jan '13

Question: How does proposal 207 (relay fetching through entry guards) affect the user metric data? Is it possible to keep that data accurate (for the current value of accurate)? ~abel

2 1

Tor Browser repository for Fedora 17 and 18
by Jamie Nguyen 17 Jan '13

17 Jan '13

Hi, I'm the maintainer for Tor package on Fedora EPEL. I've set-up a (GPG signed) repository for Fedora 17 and 18 with Tor Browser RPM packages. It optionally includes SELinux protection for the Tor Browser. (Tor client/server already has SELinux protection on Fedora.) More info here: https://jamielinux.com/articles/2013/01/tor-and-tor-browser-repository-on-f… -- Jamie Nguyen

1 0

Multiple Tor
by Bin Wang 17 Jan '13

17 Jan '13

Dear Guys, I am brand new to TOR and I feel like multiple TORs should be considered. The multiple tors I mentioned here are not only multiple instances, but also using different proxy ports for each, like what has been done here http://www.howtoforge.com/ultimate-security-proxy-with-tor) I am trying to get started with 4 tors. However, the tutorial applies to Arch Linux and I am using a headless EC2 ubuntu 64bits. It is really a pain going through the differences between Arch and Ubuntu. And here I am wondering is there anyone could offer some help to implement my idea simplicitly. 1. Four TORs running at the same time each with an individual port, privoxy or polipo or whatever are ok once it works. Like: 8118 <- Privoxy <- TOR <- 9050 8129 <- Privoxy <- TOR <- 9150 8230 <- Privoxy <- TOR <- 9250 8321 <- Privoxy <- TOR <- 9350 2. In this way, if I try to return the ip of 127.0.0.1:8118, 8129, 8230 and 8321, they should return four different ips, which indicates there are four different tors running at the same time. Then, a few minutes later, check again, all four of them should have a new ips again. I know my simple 'dream' could come true in many ways, however... I am not only new to tor, but even also to bash and python... That is why I come here and see whether some of you could light me up. These links might be useful: http://blog.databigbang.com/distributed-scraping-with-multiple-tor-circuits/ https://www.torservers.net/wiki/setup/server#multiple_tor_processes http://www.howtoforge.com/ultimate-security-proxy-with-tor Best, Bin Wang

3 4

All the problems about Stegotorous
by vmonmoonshine＠gmail.com 16 Jan '13

16 Jan '13

Hello everybody, I was talking to Roger yesterday on the IRC, and he mentioned that "[S]tegotorus ... has a whole lot of problems". I have heard this many times in different forms by now (in Florence, The sponsor F discussion, etc). But I never saw these "lot of problems" are broken down in a list, so at least one can attack them one by one. It was always "lots of problem". So, let this email be an appeal to all of you who have some problem, deficiency, architectural dissatisfaction, etc with Stegotorus, write back on this thread, so at least we have written account of these problems and dissatisfactions? Then I'll turn them into the tickets as the very first step toward their solution. Also it can serve as written account of difficulties involving the making of any HTTP transport. Thank you for your contribution in advance. Cheers, Vmon

3 2

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

16 Jan '13

Hi Roger, Thank you very much for replying to my appeal. I hope that other people who are critical of Stegotorus jump-in along the line. > 1) Like the FTE paper... I'm going to discuss your first point at the end because it is not criticism of Stegotorus per se, but of http transport in general. > 2) There also remains the issue of where you get your > covertexts. While > FTE says "we will build a brilliant regexp to characterize the format > of the thing we hide our content in" (which has its own problems -- > anything your regexp misses is a crack in the armor), Stegotorus says > "we will build a big library of example things, by crawling the > Internet, > and then we'll hide our content in them". Where does this library come > from? How does every Stegotorus bridge gets its own library? What > happens > when you reuse an item in your library? How do *clients* generate > their > own library? I think there are lots of ways to lose plausibility that > haven't been explored. > > 2') One of the proposed ways for clients to generate their library of > plausible covertexts is to basically wiretap the user and then replay > her own traffic later with the Tor flow embedded in it. First there > are messy engineering questions to tapping the user in a portable way; > but I worry even more about the privacy issues introduced by repeating > earlier traffic. Also, does it introduce new distinguishing attacks, > like "look for variations on the same request"? So one thing I implemented last summer to address 2 and 2' at least on plausibility level is this: - To setup, ST-server, you give it the address of an http server and list of files stored on that server (alternatively you are running Apache httpd on the same machine and ST-Server will go and make a list of all files in Apache document_root). - The client request the "http://ST-server/". - In reply ST-server will send the hash of the list of files - ST-client compare with the hash of its own file list (which can be zero if the client has no list). - If it matches they starts serving right away. - If not, ST-server will send the list of file to the client. (these all happens inside the steg layer of course). Moreover, now not only the steg modules are pluggable, the payload (covertext) loader is also pluggable, so if you don't like this way of loading payloads you can write your payload loader and ask ST to use that instead. > I recognize that *not* > using real client traffic also allows problems, e.g. "why is that > user, > who usually uses IE, sending a user-agent of chromium?" > This can be address as a ticket. CURL already has the option to pretend being other agents. You can just ask the user to browse 127.0.0.1:ST-Port and get the agent that way. After all I don't think, this is as a critical issue. First most people are sharing valid IPs. (I can't remember one place in Iran that I got a valid IP) So the filter has no way to say if two people are using the connection, or one person using two browsers. Let alone that, it is not uncommon to use two browsers on a same computer. The other thing is that HTTP GET request doesn't have lots of place to maneuver so it is much easier to make it exactly look like a specific browser. Long term we can make a Firefox plug-in to interact with ST on the client side. It shouldn't be hard because the payload provider is pluggable now (which also take care of the communication on the client side). > 3) What's the overhead of putting your Tor traffic through each of the > steg modules? It's my understanding that some of the Stegotorus steg > modules produce immense size overhead (since the cover-item is large, > and the part of the cover-item you can hide your message in is > relatively > small). Well, this is a usual efficiency/security trade off question. What would you tell somebody who says "but I browse the web much faster without tor...", The answer is if you have idea to provide the same service with higher efficiency then go for it. Between no access or inefficient access, personally, prefer the latter. If Obfproxy can get by, I'm not going to use ST, but what if not. Practically speaking, I have watched the entire "behind enemy lines" of you and Jacob using ST using a quite good connection, and beside 2 or 3 times that it stopped, I had a OK experience watching it. I can come up with exact value of the overhead (traffic size in bytes with st)/(traffic size without st) if you give me some time. > What are the numbers for the current steg modules that people > are > talking about / have built? There's still 3/4 of them, pdf, swf, js and js in html. Adding steg module, seems to be the least of the problems and the most out source-able task. It is relatively easy to take an existing steg algorithm and feed it to ST as a steg module. >Is there some correlation between > inefficiency > (overhead) and plausibility (indistinguishability)? Obviously. You can choose the "no-steg" steg module and then you won't have any overhead. >What are the > tradeoffs > if we adopt some sort of "choose the covertext from your library that > minimizes your overhead" policy? Stegotorus, already has something like that, it consider 10 random candidates and between them it chooses the one with the least overhead that offer the capacity requested by the chopper. It is matter of few lines of codes to say only use xx% of least overhead covertext (size/capacity which payload loader is aware of both). Other possible approach to this is to ask user for a security factor (between 0-1) and based on that the steg module knows how much of change is allowed to be done to a covertext. Writing a simple classifier (using scikit-learn e.g.) which computes simple stat features to test the effectiveness of the security factor (telling http from st) isn't a terribly ambitious task either. > 4) And then the last issue isn't so much a design issue as a community > or > resource issue -- Zack is busy being a student, I think by now, I have made change to all part of the code beside the crypto module and I know the code quite well. Though I have the same problem as Zack, but I'm expecting to graduate soon. But if we tell every potential contributor don't touch ST it will burn, then the community won't grow. Anyway, I hope putting all above points on the trac as tickets, probably is the first step. If ST get a page with a short explanation and a link to its ticket (like Flashproxy does) maybe attracts more attention. > and further > development > by SRI is complicated by their pub review requirement (which alas > applies > to their code contributions too). > I don't know about this "pub review requirement". Could you give a ref to read more about it? And now item 1. > 1) Like the FTE paper > (https://www.torproject.org/docs/pluggable-transports) the main > contribution of Stegotorus is to provide a framework for plugging in > steg > modules. There are several example steg modules to choose from. The > idea > is that even if the ones they offer now aren't suitable, if you *had* > a good one, you could just pop it in. The trouble is that I don't know > of any good ones, and I think that's a harder problem than people > think. > I think the actual question is that "are we going to provide http transport or not?" I think the situation that "I'm going to close many ports beside 80 and X and Y, then do a simple DPI so people don't divert their https on 80" is a very likely scenario. The problem that you think is "a harder problem than people think" is the secure steg problem, which we are not trying to solve here. We are banking on the fact that a accurate multilevel stat analysis is too expensive for a DPI that needs to judges GBs of data per second. In expense of efficiency you can make the steg quite hard to be detected. Suppose you only use jpeg images and you only use the LSB of the cosine coefficients. I don't see any easy way to detect the steg for a DPI on the go. > I think having some thorough explorations of 1-3 would put us in a > much > better position. > In nutshell, ST doesn't stop you from writing better steg/payload loaders so that is for 2,2' and 3 while providing a working version of them right now. Item 1, is asking "if a http transport is worth it", I think the answer is yes. Thanks again, I'm going to make some tickets for more concrete aspects of above point and share them with the list. Bests, Vmon > ------------------------------ > > Message: 2 > Date: Sun, 13 Jan 2013 23:47:44 -0700 > From: Bin Wang <binwang.cu(a)gmail.com> > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] Multiple Tor > Message-ID: > <CAJHCcVbzQcXkQZurORupLLEJBm9cJATkKqYOYkUr=km-bo34pA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Dear Guys, > > I am brand new to TOR and I feel like multiple TORs should be > considered. > The multiple tors I mentioned here are not only multiple instances, > but > also using different proxy ports for each, like what has been done > here > http://www.howtoforge.com/ultimate-security-proxy-with-tor) > > I am trying to get started with 4 tors. However, the tutorial applies > to > Arch Linux and I am using a headless EC2 ubuntu 64bits. It is really a > pain > going through the differences between Arch and Ubuntu. And here I am > wondering is there anyone could offer some help to implement my idea > simplicitly. > 1. Four TORs running at the same time each with an individual port, > privoxy > or polipo or whatever are ok once it works. > Like: > 8118 <- Privoxy <- TOR <- 9050 > 8129 <- Privoxy <- TOR <- 9150 > 8230 <- Privoxy <- TOR <- 9250 > 8321 <- Privoxy <- TOR <- 9350 > > 2. In this way, if I try to return the ip of 127.0.0.1:8118, 8129, > 8230 and > 8321, they should return four different ips, which indicates there are > four > different tors running at the same time. Then, a few minutes later, > check > again, all four of them should have a new ips again. > > I know my simple 'dream' could come true in many ways, however... I am > not > only new to tor, but even also to bash and python... That is why I > come > here and see whether some of you could light me up. > > These links might be useful: > > http://blog.databigbang.com/distributed-scraping-with-multiple-tor-circuits/ > https://www.torservers.net/wiki/setup/server#multiple_tor_processes > http://www.howtoforge.com/ultimate-security-proxy-with-tor > Best, > Bin Wang >

2 1

Orbot: request hidden service from other app
by Bernd 09 Jan '13

09 Jan '13

Hello, I'm going to write an Android app that needs a hidden service, specifically I want to implement a client for the TorChat protocol on Android. TorChat needs a hidden service to receive incoming connections and it needs to know its own .onion name to be able to advertise it to others. Some of you might know my first implementation of it for Windows came bundled with the tor executable and simply started and stopped its very own tor process with its own configuration inside its own private directory and then simply read the hostname file from the hidden service directory to learn its own .onion hostname, this was pragmatic and probably not very elegant but it was very robust and very user friendly. On Android I would now rather make use of Orbot and Orbot's Tor process instead of bundling my own Tor executable. I have seen somewhere in the tor issue tracker it was mentioned (2 years ago) that in Orbot it was planned (and a prototype existed already) to make it possible for another app to use Android's Intent-System to: * request a hidden service on port xyz * have Orbot started automatically as a result of this * have Orbot automatically configure the HS as requested * tell the App what the hostname of that HS is. Is that implemented already? If it is, does there exist any documentation or example code that makes use of it? -Bernd

2 1

Stem code review 2013-01-03
by Sean Robinson 06 Jan '13

06 Jan '13

Stem devs, This is a review of commits made to Stem from 2012-12-22 through 2013-01-03. Happy new year. I'm a fan of the new Controller.get_circuits() method. It's a nice and clever re-use of internal code. And it makes circuit-oriented method tests much more readable. Controller.get_circuit() is another good idea. A positive feedback loop... Using defaults for getters is betters[0]. This allows developers to choose whether to accept the exception or use their own reasonable default. I like the synchronous[1] interface to Controller.extend_circuit(). It's a good idea and a good internal re-use of event handling. Even better, the sync interface is optional. I did find the 'assert extended == "EXTENDED"' test after is_ok() to be strange, I cannot find where Tor has ever returned anything other than "250 EXTENDED" on success for an EXTENDCIRCUIT command. This may be more verification of results than is warranted. If Damian and Ravi agree, I would be happy to submit a patch removing this line. With the recent changes[2] to ExitPolicy and related classes, I dove into research on this topic. But, there is still much I don't understand, so please be careful with the following comments. 1) There is a discrepancy in class naming (i.e. MicroExitPolicyRule vs MicrodescriptorExitPolicy) about which I vote to rename MicrodescriptorExitPolicy to MicroExitPolicy. 2) How can a lightweight class be a subclass of a heavy class and be lightweight? MicrodescriptorExitPolicy is a subclass of ExitPolicy and MicroExitPolicyRule is a subclass of ExitPolicyRule. I concentrated on MicroExitPolicyRule and ExitPolicyRule. What I found: a) There are a few small attributes (i.e. _address_type, _mask_bin, _addr_bin, _mask, _masked_bits) in ExitPolicyRule and not in MicroExitPolicyRule. b) There is minimal extra processing of get_*() methods in ExitPolicyRule. c) Private methods (i.e. _get_address_bin, _apply_portspec, _apply_addrspec, _get_mask_bin) from ExitPolicyRule are still in MicroExitPolicyRule and cause exceptions (e.g. "AttributeError: 'MicroExitPolicyRule' object has no attribute '_mask_bin'") when called. d) However, i) sys.getsizeof(ExitPolicy("accept 1.1.1.1:34")) == 64 bytes ii) sys.getsizeof(MicroExitPolicyRule(True, 34, 34)) == 64 bytes iii) I made a mutant MicroExitPolicyRule that was a direct subclass of object and sys.getsizeof(MicroExitPolicyRule(True, 34, 34)) == 64 bytes I'm not sure these MicroExitPolicy* classes can be considered lightweight. Would a class with least common attributes (e.g. BaseExitPolicyRule) from which ExitPolicyRule and MicroExitPolicyRule descended make sense. But, considering the size results in 2)d), is it worth the time to optimize this area? And lastly, I want to quote my favorite line from these recent commits[last]: address = address.lstrip('[').rstrip(']') Wait, you can do that? [0]: https://gitweb.torproject.org/stem.git/commit/ffdd61ea41ca844047ac57725639a… [1]: https://gitweb.torproject.org/stem.git/commit/f716fedc97ea3cc522571ad8bd505… [2]: https://gitweb.torproject.org/stem.git/commit/da65f282699d3e8e763e1f3ba3c76… and https://gitweb.torproject.org/stem.git/commit/d35b9c737e320500fa6cfdfa87453… [last]: https://gitweb.torproject.org/stem.git/commit/683b1ba479f2aff3c277e0ff53bdc… -- Sean Robinson

2 1

Re: [tor-dev] RFC on obfs3 pluggable transport
by Ian Goldberg 05 Jan '13

05 Jan '13

On Wed, Dec 12, 2012 at 03:13:59AM +0200, George Kadianakis wrote: > Ian Goldberg <iang(a)cs.uwaterloo.ca> writes: > > > [Should we not be copying tor-dev on this thread?] > > > > We definitely should. > > Is it OK if I forward the whole thread to tor-dev (including this mail > and your reply)? Feel free to do it yourself too if you want. I'll copy tor-dev on this email, and not snip things in order that context is mostly preserved. If you think some past snippage should be restored, feel free to forward that as well. > BTW, in my first email, I had tor-assistants CCed, but you stripped it > off when you replied, so I didn't add it again :) Oops; that was unintentional. My bad. But tor-dev is better, anyway. > > On Fri, Dec 07, 2012 at 02:09:21AM +0200, George Kadianakis wrote: > > <snip> > > > >> > You'll also need to be careful about the exact protocol to select > >> > whether to use the curve or the twist; I remember we discussed this at > >> > PETS, sitting outside the wine tasting. > >> > > >> > >> Ugh. I admit that even though I remember our discussion at PETS, I > >> don't recall that part of our discussion. What do you mean by "the > >> exact protocol to select whether to use the curve or the twist"? > >> > >> My plan would be to choose randomly between the base point of the > >> curve and the base point of its twist, make a public key using the > >> randomly chosen base point, and finally send the public key to the > >> other party. Looking at the Telex paper, this is similar to the > >> creation of a_0/a_1 in the 'Setup' phase of appendix 'Tagging Details'. > >> > >> IIUC the other party shouldn't care whether the public key was created > >> using the curve or its twist, and can just do another point > >> multiplication to derive the shared secret. > >> > >> Is this the protocol you are talking about, or am I getting my stuff > >> wrong? > > > > That works if clients know a pair of public keys for the bridge in > > advance. It was unclear to me whether this would be the case. Is it? > > Can we put public keys in with the bridge descriptors? In this case, > > you'd need 42 octets for the public key. The spec I see in gitweb > > doesn't assume that. Rather, it has all operations being performed on a > > common curve. > > > > Correct. Let's assume that clients _don't_ have any shared-secrets > beforehand. It makes our transport more deployable and usable, and it > doesn't rely on non-implemented pluggable transport features. > > (FWIW, adding public keys (or other info) to bridge descriptors is > supported by the pluggable transport spec (DECLARE option), but it's > not implemented. Support for passing public keys (or other info) to > pluggable transport proxies is implemented in ticket #3594 but it's > not ready for merge yet.) > > > The trick is that both sides need to use the *same* curve: either the > > main curve or the twist. So if I watch a host I suspect is an > > obfs3proxy responder and find that the first 21 bytes it outputs is > > always on the same curve as the first 21 bytes it received, that's good > > evidence for my suspicion. > > > > I see. > > Let me formalize the protocol I tried to describe in my previous mail. > > Alice randomly selects a bit 'b' \in {0,1}. Similar to Telex, the bit > 'b' selects whether Alice will use the normal curve E or its twist E'). > Depending on the bit 'b', Alice generates a public key on E or E'. > > Now, Alice sends to Bob her public key along with padding, as > described in the obfs3 spec. > > Bob receives Alice's message and parses the first 21 bytes, which he > considers her public key. Bob checks whether the public key fits E or > E'. Depending on the curve, Bob loads up the correct domain > parameters, does a point multiplication with Alice's public key and > his private key, and derives the shared secret. > > Now, Bob does the same dance with Alice, so that Alice can also derive > the shared secret. > > What's the problem with this protocol? When Bob "does a point multiplication with Alice's public key", you mean "Bob picks a private key y, and multiplies Alice's public key by y to yield the shared secret". Note that the resulting shared secret (y times Alice's public key) will be in the same group (E or E') that Alice's public key is in. Now what does Bob send to Alice? Bob should be sending y times the generator of the group. Which group? If Bob and Alice are to agree on the shared secret, it has to be the same group Alice used. Otherwise, Alice's computation will necessarily end up different from Bob's (since they'd be in different groups) and the two secrets won't match. So in order for this protocol to work, Bob has to always choose the same group he received as a public key from Alice. But that's now a distinguisher for the protocol: if I'm watching someone I think is running an obfsproxy3 bridge, and I notice that the first 21 bytes he receives on any TCP connection always lies in the same group as the first 21 bytes he sends in response, then I can be pretty confident in my suspicion. > I think it's similar to how Telex generates and inspects tags: Looking > at the algorithm of the "Telex tag inspection" section of the Telex > paper, it seems to me that the Telex station doesn't know whether the > tag is on the curve or its twist either. The big difference is that Telex uses *static* DH (and gains forward secrecy by rotating keys): the client comes pre-loaded with (rP, rP') where P and P' are generators of E and E'. The Telex client then randomly picks Q to be either P or P', and randomly picks s, and sends sQ. The Telex station then can tell which group sQ is in, and multiply sQ by r. Conversely, the client uses whichever of rP and rP' corresponds to its choice of Q, and multiplies that by s. Then the secrets match. The important distinction is that in Telex, the client *already knows one public key in each group*. In the above obfsproxy3 proposal, it does not. > I tried to find how the Telex station code does it, but I didn't > manage to find the telex-relay code on the Internet :( Indeed, I don't believe the UMich people have (yet?) published it. > > Are we married to using elliptic curves? Is performance a serious > > concern at the moment? If not, it may be easier to use Z_p, while still > > using a trick similar to the "twist": > > > > No, we are not married to elliptic curves. It was just that the only > trick I knew on hiding DH public keys was the Telex trick, which uses > ECC. > > > Let p = 3 mod 4 be prime, with q=(p-1)/2 also prime, and p is at least > > 1536 bits. (2048 if there's room.) [Use group 5 or group 14 from RFC > > 3526.] Let g be a generator of the order-q subgroup of Z_p^* (g=2 for > > the two above groups from the RFC.) > > > > To pick a private key, pick a random 1536-bit (or 2048-bit) number, and > > force the low bit to 0. So there are 1535 (2047) bits of randomness, > > which is the size of q. Let x be that private key. Let X = g^x mod p. > > > > Here's the trick: When you send the public key, randomly decide to send > > either X or p-X. That will make the public key part a uniform 1536-bit > > (2048-bit) string (well, negligibly different from uniform). > > > > The other side constructs y and Y=g^y mod p in the same way, and sends > > either Y or p-Y. > > > > Note that both (p-Y)^x = Y^x mod p since x is even, and similarly > > (p-X)^y = X^y mod p, so key derivation goes through unchanged. > > > > The downside of the larger public keys is that it puts a lower bound on > > the size of the data sent by the initiator before the responder answers. > > > > Ha. The Z_p stunt you describe is nifty! I will seriously consider it, > if the telex-curve protocol doesn't work out without a pre-shared > public key. Note that the above protocol assumes that p is very close to a power of 256, but that's true of the RFC 3526 groups 5 and 14 I pointed to. > > On a side note, in Philipp Winter's "put the hash there" trick, I think > > it would be better to use HMAC(SHARED_SECRET, "obfsproxy3 delimiter > > string") rather than h(SHARED_SECRET). > > > > True. > > As a matter of fact, we should probably have two HMACs, one for the > initiator and another for the responder. Otherwise, hashing the > SHARED_SECRET with a common key, will result in HASH_LEN bytes that > appear both in the initiator's and in the responder's traffic stream. Yes indeed. - Ian

2 4

Andrea's December 2012 status report
by Andrea Shepard 05 Jan '13

05 Jan '13

Hi all, In December 2012, I: * Worked on parallel relay crypto, but didn't finish implementation in time for the Dec. 10 merge deadline, so that'll be headed for 0.2.5 * Reviewed a bunch of patches for 0.2.4: * CREATE2/EXTEND2, NTOR and curve25519 (bugs 7199 and 7202) * IPv6 exits (bug 5547) * Per-circuit DNS cache and AutomapAllHosts (bugs 7570 and 7571) * TLS ECDHE (bug 7200) * Fallback directories (bug 572) * Directory guards (bug 6526) * Reviewed a patch submitted in bug 7590 In January 2013, I plan to: * Get back to and hopefully wrap up parallel relay crypto * Implement some changes to the patch for bug 7590 needed for portability that I recommended when reviewing it. * Investigate reports that bug 7350 has risen from the grave -- Andrea Shepard <andrea(a)torproject.org> PGP fingerprint: 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5

1 0

Re: [tor-dev] Cupcake: browser extension for flash proxies
by Griffin Boyce 04 Jan '13

04 Jan '13

On Fri, Jan 4, 2013 at 5:42 PM, David Fifield <dcf(a)cs.stanford.edu> wrote: > > Thank you for doing this. Would you please add this information to the > ticket at https://trac.torproject.org/projects/tor/ticket/7721? This is > the ticket for creating a browser addon. You can create an account or > use the anonymous account cypherpunks:writecode. There are people > watching the ticket who will be interested in helping you test. > No sweat - didn't realize that there was a thread about it already. https://trac.torproject.org/projects/tor/ticket/7721#comment:5 > We will probably be moving to an all-opt-in model for flash proxy. Your > addon should send the flashproxy-allow=1 cookie, if it doesn't already It doesn't, but I'll make that update > At this point, it will help if you can keep it pointing to the same > embed page. As we are on the verge of deployment, we may need to make > changes to the proxy program quickly. > > David Fifield > Sounds good to me. I don't think it would be too difficult to get a couple thousand users through the Chrome Web Store. Best, Griffin Boyce

1 0

Cupcake: browser extension for flash proxies
by Griffin Boyce 04 Jan '13

04 Jan '13

Hi all, Made this extension for Google Chrome to extend the concept of the Flash Proxy, and make it easy for users to create bridges. (and as a result cause a bunch of fairly robust bridges to be made). The concept could be used in addons for FireFox, Opera, or Safari as well, since they all allow processes to run in the background. Benefits: * Allows people to opt-in to becoming flash proxies, rather than current opt-out model * Works in Chrome OS * Takes all guesswork out of making a bridge * Flash proxies made with Cupcake have a substantially longer uptime than those using site visitors * Uses less memory than either Tor BB or Vidalia Source code: https://github.com/glamrock/cupcake Now that I've tested it and it seems to work well, I'd love to get input and suggestions on it. If it's useful, I'll submit it to the Chrome Web Store. Right now it uses the Stanford project site's embed page. If there's much interest in this, I'll switch to a dedicated site since it's maybe not fair to send that many requests to them ^_^; Input, ideas, and tomatoes welcome =) Best, Griffin Boyce -- "What do you think Indians are supposed to look like? What's the real difference between an eagle feather fan and a pink necktie? Not much." ~Sherman Alexie PGP Key etc: https://www.noisebridge.net/wiki/User:Fontaine

2 1