October 2012 - tor-dev - lists.torproject.org

Proposal 206: Preconfigured directory sources for bootstrapping
by Nick Mathewson 11 Oct '12

11 Oct '12

Filename: 206-directory-sources.txt Title: Preconfigured directory sources for bootstrapping Author: Nick Mathewson Created: 10-Oct-2012 Status: Open Target: 0.2.4.x Motivation and History: We've long wanted a way for clients to do their initial bootstrapping not from the directory authorities, but from some other set of nodes expected to probably be up when future clients are starting. We tried to solve this a while ago by adding a feature where we could ship a 'fallback' networkstatus file -- one that would get parsed when we had no current networkstatus file, and which we would use to learn about possible directory sources. But we couldn't actually use it, since it turns out that a randomly chosen list of directory caches from 4-5 months ago is a terrible place to go when bootstrapping. Then for a while we considered an "Extra-Stable" flag so that clients could use only nodes with a long history of existence from these fallback networkstatus files. We never built it, though. Instead, we can do this so much more simply. If we want to ship Tor with a list of initial locations to go for directory information, why not just do so? Proposal: In the same way that Tor currently ships with a list of directory authorities, Tor should also ship with a list of directory sources -- places to go for an initial consensus if you don't have a somewhat recent one. These need to include an address for the cache's ORPort, and its identity key. Additionally, they should include a selection weight. They can be configured with a torrc option, just like directory authorities are now. Whenever Tor is starting without a consensus, if it would currently ask a directory authority for a consensus, it should instead ask one of these preconfigured directory sources. I have code for this (see git branch fallback_dirsource_v2) in my public repository. When we deploy this, we can (and should) rip out the Fallback Networkstatus File logic. How to find nodes to make into directory sources: We could take any of three approaches for selecting these initial directory sources. First, we could try to vet them a little, with a light variant of the process we use for authorities. We'd want to look for nodes where we knew the operators, verify that they were okay with keeping the same IP for a very long time, and so forth. Second, we could try to pick nodes for listing with each Tor release based entirely on how long those nodes have been up. Anything that's been a high-reliability directory for a long time on the same IP (like, say, a year) could be a good choice. Third, we could blend the approach and start by looking for up-for-a-long-time nodes, and then also ask the operators whether their nodes are likely to stay running for a long time. I think the third model is best. Some notes on security: Directory source nodes have an opportunity to learn about new users connecting to the network for the first time. Once we have directory guards, that's going to be a fairly uncommon ability. We should be careful in any directory guard design to make sure that we don't fall back to the directory sources any more than we need to. See proposal 207.

1 0

10 days left for proposals for hard stuff [Re: Reminder: Big/tricky/interesting features for 0.2.4 need proposals by 10 October]
by Nick Mathewson 08 Oct '12

08 Oct '12

On Mon, Sep 17, 2012 at 11:47 AM, Nick Mathewson <nickm(a)freehaven.net> wrote: > Hi, all! > > From https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024 : > > "October 10, 2012: Big feature proposal checkpoint. Any large > complicated feature which requires a design proposal must have its > first design proposal draft by this date." > > There are only 23 days till October 10. If there's something you want > in 0.2.4.x, and it is the kind of thing that needs a design proposal, > and there is no proposal yet, it could be time to start writing! > > What needs a design proposal? Generally: anything that involves a > change to the Tor protocol; anything whose security implications are > nontrivial and need discussion; and anything that will change any Tor > specification. Err on the side of "it needs a proposal." > > What is a "large complicated feature"? Please assume I'm going to be > extremely grumpy here, and err on the side of "it is big". If the > writeup of the proposal that explains how it works, or why to do it > this way is going to take more than a few paragraphs, it is probably > 'big' or 'complex'. > > (Note to would-be system-gamers: Please don't send a sketchy > incomplete draft as a placeholder to get your foot in the door. That's > not cool. If you don't have a draft ready, the feature can wait till > 0.2.5.) > > (Note also: a feature proposal by this deadline is a necessary > condition for getting your big/tricky/complicated feature into 0.2.4, > but not a sufficient condition. It also needs to have a working > implementation on schedule.) > > (Note finally: This is not a promise to not merge stuff that violates > this deadline, but I sure will be trying not to merge such stuff.) > > yrs, > -- > Nick

3 3

resistance to rubberhose and UDP questions
by Eugen Leitl 06 Oct '12

06 Oct '12

I've had an IRC session with the designer of cjdns (on cjdns) who made a few interesting points, and suggestions. Comments? Verbatim chat snip below. 18:03 <@cjd> if you took the components from cjdns, you could build a TOR like protocol which used UDP if possible and made connections much faster 18:04 <+eleitl> I wonder why they didn't choose UDP 18:05 <@cjd> you need to fall back on tcp in case you're firewalled to hell 18:05 <+eleitl> Apparently, they're thinking about it https://blog.torproject.org/blog/moving-tor-datagram-transport 18:06 <@cjd> problem with tor is (correct me if I) 18:06 <@cjd> 'm wrong) 18:06 <@cjd> the directory is signed by the tor foundation 18:07 <@cjd> so they can sign a fake directory and run a bunch of directory servers and when Alice connects to their directory server, they give her a bunch of fake nodes 18:07 <@cjd> run their own botnet with fake tor nodes so your circuit is always owned 18:07 <+eleitl> I don't really know for sure, but there's intrinsic trust to Tor developers, yes. 18:08 <+eleitl> You can run your own Tor network, though. 18:08 <+eleitl> Some botnets do that. 18:08 <@cjd> I trust them to make the software right, esp. since I could check if they did. 18:09 <@cjd> But a little arm twisting can change someone's motives pretty fast. 18:09 <+eleitl> Maintaining signing secrets is a problem. 18:09 <+eleitl> They should have used a P2P design. 18:10 <@cjd> If someone (with government hat?) tells you they can make your life hell... I wouldn't fault them for doing what the man says. 18:10 <@cjd> *wouldn't fault you 18:10 <+eleitl> I'll try bugging some Tor developers about that scenario, and see how they squirm. 18:11 <+eleitl> Also, the UDP connection thing. 18:11 <@cjd> You can "stack" your circuit setup packets if you're using UDP 18:11 <@cjd> stack -> all headers in the same packet 18:12 <@cjd> cjdns does the same thing 18:13 <+eleitl> Can I use snippage from this chat verbatim, or will I need to rephrase? 18:14 <@cjd> sure go ahead 18:14 <+eleitl> Thanks! 18:14 <@cjd> can only speak for myself ofc 18:14 <+eleitl> Sure.

6 7

how to configure the window size of tor browser
by jiang song 05 Oct '12

05 Oct '12

Hi, I want to make the tor browser with certain size, eg. 650*650, so as to do some test on some webpages I used command line like: App/Firefox/firefox --profile Data/profile -height 650 -width 650 but it doesn't work I tried to modify localstore.rdf in Data/profile, but it is dynamically changed by running the browser does anybody know how the size is set in the TBB and which configuration file can I modify ? thanks

2 3

about plugins enable/disable and window size
by esolve esolve 05 Oct '12

05 Oct '12

Hi, I want to control the window size of Firefox browser and whether a plugin is enabled or disabled when a new firefox browser is opened. Currently I'm using a Tor browser which is a modified firefox browser, when I open it, the window size is set by default and flash plugin is by default disabled. even if I try to set them mannually, the next time I open a new firefox window, the setting return to default. I want to know which configuration files or what part of the source codes are controling this default setting, and I want to modify it. can anybody give me some solution or hints? thanks!

1 0

The Tor Project is looking for a Pluggable Transport developer
by Roger Dingledine 05 Oct '12

05 Oct '12

We have funding initially for part-time work, and hopefully it will grow into full-time work. Please spread the word! This job is for the development and maintenance of the flash proxy circumvention system, with a focus on deployment and getting tools in the hands of users: https://crypto.stanford.edu/flashproxy/ https://gitweb.torproject.org/flashproxy.git/ If it goes well, we might have you branch out into improving usability and deployability of other Tor pluggable transports. Applicants must be familiar with Python, JavaScript, and web technologies, particularly WebSocket. You will do usability testing and be in charge of producing binary packages of client software for GNU/Linux, Windows, and OS X. The system's supporting infrastructure is already in place, but may require changes depending on the future development of the client programs. There also is the potential for the development and implementation of new covert rendezvous methods that may have broader use outside the flash proxy system. You will be assisted and mentored by David Fifield, the primary developer of the flash proxy software and co-author of its research paper, and all-around good guy. See the job posting for information on how to apply and what you need to send in with your application: https://www.torproject.org/about/jobs-pluggabletransport Thanks! --Roger

1 0

resistance to rubberhose and UDP questions
by Eugen Leitl 04 Oct '12

04 Oct '12

I've had an IRC session with the designer of cjdns (on cjdns) who made a few interesting points, and suggestions. Comments? Verbatim chat snip below. 18:03 <@cjd> if you took the components from cjdns, you could build a TOR like protocol which used UDP if possible and made connections much faster 18:04 <+eleitl> I wonder why they didn't choose UDP 18:05 <@cjd> you need to fall back on tcp in case you're firewalled to hell 18:05 <+eleitl> Apparently, they're thinking about it https://blog.torproject.org/blog/moving-tor-datagram-transport 18:06 <@cjd> problem with tor is (correct me if I) 18:06 <@cjd> 'm wrong) 18:06 <@cjd> the directory is signed by the tor foundation 18:07 <@cjd> so they can sign a fake directory and run a bunch of directory servers and when Alice connects to their directory server, they give her a bunch of fake nodes 18:07 <@cjd> run their own botnet with fake tor nodes so your circuit is always owned 18:07 <+eleitl> I don't really know for sure, but there's intrinsic trust to Tor developers, yes. 18:08 <+eleitl> You can run your own Tor network, though. 18:08 <+eleitl> Some botnets do that. 18:08 <@cjd> I trust them to make the software right, esp. since I could check if they did. 18:09 <@cjd> But a little arm twisting can change someone's motives pretty fast. 18:09 <+eleitl> Maintaining signing secrets is a problem. 18:09 <+eleitl> They should have used a P2P design. 18:10 <@cjd> If someone (with government hat?) tells you they can make your life hell... I wouldn't fault them for doing what the man says. 18:10 <@cjd> *wouldn't fault you 18:10 <+eleitl> I'll try bugging some Tor developers about that scenario, and see how they squirm. 18:11 <+eleitl> Also, the UDP connection thing. 18:11 <@cjd> You can "stack" your circuit setup packets if you're using UDP 18:11 <@cjd> stack -> all headers in the same packet 18:12 <@cjd> cjdns does the same thing 18:13 <+eleitl> Can I use snippage from this chat verbatim, or will I need to rephrase? 18:14 <@cjd> sure go ahead 18:14 <+eleitl> Thanks! 18:14 <@cjd> can only speak for myself ofc 18:14 <+eleitl> Sure.

1 0

Damian's Status Report - September 2012
by Damian Johnson 04 Oct '12

04 Oct '12

Hi all. As is often the case work and such meant not too much time for tor. For September all I have to report is... * Network Status Document Parsing This has been my main focus for September and it's still not finished... but it's close! Version 3 document parsing just has a couple days of work left, then abstracting it to cover v2 documents and microdescriptors should be relatively easy-ish. I'm really looking forward to merging this feature branch. It has grown quite monstrous... https://gitweb.torproject.org/user/atagar/stem.git/shortlog/refs/heads/docu… * Stem Documentation Hosting For a while now I've had a TODO item for making a nightly cron that built and hosted Stem's new sphinx documentation. I was about to do this when I recalled that meejah once recommended ReadTheDocs, a service that does... well, exactly that. After a few minor bumps [1][2][3] it's now live... https://stem.readthedocs.org/ We definitely need to put effort into making them more reader friendly. At present it's just a dump of all the pydocs which, while informative, is actually a bit overwhelming for new users. Module summary pages would greatly help. * MAPADDRESS Support Ravi submitted a patch for adding MAPADDRESS support to stem's controller. It's a nice addition, especially the integ test... https://trac.torproject.org/6951 * Arm Issues Looked into a couple arm issues... - Tor's start time didn't show up if the system has proc contents but we fail to parse it [5]. - Can't connect when using a control socket with password auth [6]. * Updated Dev Wiki In response to a potential volunteer I wrote a summary of several development tasks [4]. Updated stem's wiki with what was in that email... https://trac.torproject.org/projects/tor/wiki/doc/stem Cheers! -Damian [1] https://github.com/rtfd/readthedocs.org/issues/255 [2] https://github.com/rtfd/readthedocs.org/issues/256 [3] https://gitweb.torproject.org/stem.git/commitdiff/705b61674e8cec9e5608a32c6… [4] https://lists.torproject.org/pipermail/tor-dev/2012-September/004021.html [5] https://trac.torproject.org/6862 [6] https://trac.torproject.org/6881

1 0

gsathya's September devlog
by Sathyanarayanan Gunasekaran 03 Oct '12

03 Oct '12

Tickets I hacked on, closed, discussed, code reviewed, etc - ### Pyonionoo * Hacked on the Pyonionoo front end to make it deployable. I've mostly finished implementing all the features. Thanks to karsten for the really fast code reviews! #6708: Pyonionoo returns code 500 for a few parameters #6954: Internal Pyonionoo thread prints out traceback after 1 minute #6953: (relays|bridges)_published in Pyonionoo should not depend on relays/bridges contained in result #6956: lookup and country parameters in Pyonionoo should not be case-sensitive #6955: Illegal value for type parameter leads to uncaught exception in Pyonionoo #6707: Pyonionoo leaves out "relays[ _published]" when asking only for bridges ### Onionoo #6864: search shouldn't use space separated values ### Metrics Analysis #1854: Investigate raising the minimum bandwidth for getting the Fast flag * Made https://pad.riseup.net/p/tormetrics with asn and Aaron's help -- need to start working on it rsn. ### Atlas #6711: Replace full exit policy with exit policy summary on relay details page ### Compass #6618: convert compass to a single page app #6677: add a 'total' line at the bottom of the table #6818: compass appears broken #6807: Add a loading image when doing an Ajax request #6639: Rename navigation bar entries, add About page and logo #6691: BaseFilter isn't really an abstract class... yet #6959: compass calls itself tor metrics Things to do in October - * Deploy pyonionoo front end. * Hack on my undergrad thesis - Measuring the diversity of Tor network * Restart work on pyonionoo back end.

1 0

gsathya's August devlog
by Sathyanarayanan Gunasekaran 03 Oct '12

03 Oct '12

Tickets I hacked on - ### Compass #6498 - make compass, add FastExits, AlmostFastExits options #6679 - Make Compass' website interface more intuitive #6618 - Convert Compass to a single page app #6692 - Displaying more information when using 'group by' feature #6696 - add Byte/s to Advertised Bandwidth column #6617 - fix links to atlas #6681 - change top to default to -1 * Code reviewed Karsten's patches to #6680, #6702, #6693.

1 0