- tor-dev - lists.torproject.org

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

Tor's current traffic scheduling
by Sambuddho Chakravarty 03 Oct '12

03 Oct '12

Hi All I am a bit curious to know how does the traffic scheduling work in the present Tor distributions. Is it EWMA or the old round robin method ? Thanks Sambuddho

2 2

automation of open links in new tab in TBB
by jiang song 30 Sep '12

30 Sep '12

Hi, If I use firefox, I can use a simple command line to open a link in a new tab automatically, like firefox www.google.com now I want to open TBB first, and then open a link in a new tab, is there any script or method to automate this operation? I need this automation for some experiment, I know TBB is a modified firefox, so if there are TBB developes here, they may know how to do this, thanks!

2 5

Help with pf and iOS
by sid77＠slackware.it 28 Sep '12

28 Sep '12

Hi all, it took me a year or so but I've finally managed to build Tor for iOS with a working support for TransPort, as you can see on: https://github.com/sid77/evelyn/blob/master/tor/make.sh The next natural step is to hack together full device torification as iOS jailbroken devices can run pf (without ALTQ support). I'm not very comfortable with pf and pfctl so my first step was to head out to https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#BSDPF looking for some clue. However, jailbroken iOS' ifconfig can not bring up a second loopback interface (I think the kernel is not allowing it) so I had to test out some custom rules, my current pf.conf is as follow: -8<- scrub in rdr pass on lo0 inet proto tcp all -> 127.0.0.1 port 9040 rdr pass on lo0 inet proto udp to port domain -> 127.0.0.1 port domain block return out pass quick on lo0 keep state pass out quick inet proto tcp user nobody flags S/SA modulate state pass out quick route-to lo0 inet proto udp to port domain keep state pass out quick route-to lo0 inet proto tcp all flags S/SA modulate state -8<- taken from: https://github.com/sid77/mobiletor/blob/master/pf.conf I apply it running this script: https://github.com/sid77/sbsettingstor/blob/master/com.sbsettingstor.enable Tor is running as user nobody (not really secure but I still have to figure out system user management on the platform) and answering DNS queries on 127.0.0.1:53. This solution is failing *REALLY* hard as I managed to run into a kernel panic as soon as I tried to generate some traffic with Mobile Safari or Cydia. Is there any pf guru out there which can give me some insights? Ciao, Marco

4 4

automatic play of video with webbrowser
by esolve esolve 26 Sep '12

26 Sep '12

Hi, all: I want to investigate on video streaming on tor. I want to use tor and browser to play some videos for many times so I want to automate the operation. Are there any scripts that can automate the playing of videos(like from youtube,etc) I know playing videos can impediment the anonymity, but that is not my concern. Thanks!

2 1

information about "last_restarted"
by succer110＠tiscali.it 25 Sep '12

25 Sep '12

Hi everyone tor devel! I would like to know more information about last_restarted information. - It's possibile to forge this kind of data or is somehow certified by the tor network? Sometime, while sampling hourly some data by onionoo i've noticed some difference in the uptime by + or - a few seconds in this value. - Any idea of how this is possible?! - In which file do i find the code that handle this value? Thank you! Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/

2 1

Email-based rendezvous for flash proxies
by David Fifield 25 Sep '12

25 Sep '12

I have made a design and written some code for an email-based registration system for flash proxy clients. Registration is the process by which a censored client sends its IP address to request service from an external proxy. In summary, a censored client sends its address in encrypted email over SMTP over TLS to a distinguished email address. A program running on the flash proxy facilitator makes an IMAP connection over TLS, polls for messages, then decrypts them and registers the addresses withing. The email messages are sent by a registration helper program, not the client's own email account, and they appear to come from a dummy address. More information is in the ticket: https://trac.torproject.org/projects/tor/ticket/6383#comment:5 I would appreciate a second look at the design, especially the use of crypto. The ticket's comment number 5 calls out some particular features. This is our first registration system with a claim to being hard to block. This is step 1 that goes through the firewall in the diagram at http://crypto.stanford.edu/flashproxy/#how-it-works. The censor sees a TLS session with a Gmail MX server, followed later by an incoming connection from a flash proxy at a previously unseen IP address. What makes this different than other circumvention ideas is that nothing is sent directly to any published or unpublished Tor relay. David Fifield

1 0

Fwd: New HS protocol
by Robert Ransom 19 Sep '12

19 Sep '12

Note that this scheme is not quite safe to implement with Ed25519 or other DSA-like signature schemes as described; the base point needs to be multiplied by the same number as the public-key group element. ---------- Forwarded message ---------- From: Robert Ransom <rransom.8774(a)gmail.com> Date: Wed, 19 Jan 2011 08:42:40 -0800 Subject: New HS protocol To: Kadianakis George <desnacked(a)gmail.com> Cc: [redacted], [redacted], tor-assistants(a)torproject.org I wrote up the following new HS protocol on 2011-01-13, but haven't sent it out anywhere publicly visible yet. The only system I have come up with to hide a hidserv's identity key from the directory servers requires that the hidserv use a discrete-log cryptosystem for its identity key, and that the HS address contain enough of the identity key that a client can compute a scalar multiple of the identity key. (For example, the identity key can be a point on an elliptic curve in Weierstrass form, and the HS address can be the point's x coordinate.) The system designer chooses a group, an element P of prime order p in that group, and a publicly computable one-way function h mapping bitstrings to integers in the interval [1, p-1]. The HS chooses a secret key n and computes its public key nP; its descriptor index in time period t can be computed by any party which knows its public key as h(t | nP)*nP, but only the HS will know the discrete logarithm h(t | nP)*n of the descriptor index with base P. The HS can therefore compute an ECDSA signature, for example, which the directory server can verify using the descriptor index as a public key. Robert Ransom

1 0

Italy - third highest number users
by SiNA Rabbani 19 Sep '12

19 Sep '12

Somehow in August, Italy got a few thousand additional Tor users and became third as far as usage of Tor: > https://metrics.torproject.org/users.html?graph=direct-users&country=it#dir… > Country Mean daily users > United States 60769 (14.30 %) > Iran 43709 (10.28 %) > Italy 37306 (8.78 %) > Germany 36672 (8.63 %) Any insight? --SiNA

1 0

Reminder: Big/tricky/interesting features for 0.2.4 need proposals by 10 October
by Nick Mathewson 17 Sep '12

17 Sep '12

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

1 0

DNS(SEC) draft update
by Ondrej Mikle 16 Sep '12

16 Sep '12

Hi Nick, I've revised the DNS draft, attaching it. In section 4 there are some options for integration with libunbound, but each of them requires some work with the stock libunbound code. Ondrej

3 3

Re: [tor-dev] Tor Volunteer
by Damian Johnson 15 Sep '12

15 Sep '12

> Damian, > > I saw on the tor-dev mailing list you would be happy to have help with > Python related Tor work. I'm game. I'd love to help the Tor Project. Hi Scott. Glad you want to help! These are great questions so I'm looping in Ravi (another developer who's actively hacking on stem) and tor-dev in case other people are interested. > I looked through the Easy bugs for Arm but it seems that Stem is where the > effort is going now. Yup. Arm was experiencing really bad feature creep so I swapped my focus to stem around a year back. Here's the relevant links for stem... * Development Wiki https://trac.torproject.org/projects/tor/wiki/doc/stem * Gitweb https://gitweb.torproject.org/stem.git * Bug Tracker http://tinyurl.com/stem-bugs > Should I focus on Stem? > Do you have a list of easier tasks to get my feet wet with? Sure! We're currently working to make it feature complete and prepare for its initial release. Development tasks tend to fall into a few general categories... =================== Controller Functionality =================== Stem is primarily a replacement for TorCtl, a controller library used by several of our other projects (arm, SoaT, TorBEL, etc). Ravi's been focusing on making the Controller class feature complete. This is mostly located in... https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/control.py Some nice introductory tasks here would be... * Add methods for querying relay descriptors The first bits of this is very easy, while the later parts get a bit more interesting... - Add a get_relay() method that calls get_info("desc/id/[fingerprint]") then return a ServerDescriptor for it. - Write unit and integ tests for the addition. - [tricky part] Add a get_all_relays() method that provides an iterator for all of the descriptors. The tricky bit is that the BaseController provides discrete controller messages, but in this case the "GETINFO desc/all" output is so large that we want to process it while it comes in. This means changing stem's underlying message processing system. * Split low and high level controller methods The Controller class is growing to be pretty bulky, and its methods can generally be split into two categories... - Low level methods that simply mirror what the control-spec provides. - Higher level methods (like the get_relay() and get_all_relays() above) which are more user friendly and build on what the control spec provides. Ravi: Do you have any thoughts on this? Do you think this would be a good way to break up the controller, or would this just make it more confusing? Alternatively we could wait until we try using stem in arm to see if this makes sense or not... =============== Descriptor Parsing =============== This is where my focus has been for the last couple weeks. A controller needs to be able to parse Tor's descriptor content (GETINFO's desc, ns, and md responses). This has expanded to include file descriptors and other descriptor content, so stem can be used as a python replacement for MetricsLib. This is useful for projects like Onionoo's python counterpart. This is a somewhat dry part of stem to work on, so unless you like reading specs and writing a parser for them this might not be a great section to work on. That said, if detail oriented parsing and validation sounds interesting then there's lots 'o tasks here. ====== Clients ====== Stem doesn't yet have any clients, and will certainly need some before we make a release in order to work out the kinks. Our plan for this is... * Port arm's interpretor Arm's control interpretor is actually a standalone script that can, with a little work, be used independently from the rest of arm. It would be interesting to see what an stem based control interpretor would look like... * Port arm's torTools module Arm makes very heavy use of the controller, and abstracts all of its TorCtl usage behind a wrapper module... https://gitweb.torproject.org/arm.git/blob/HEAD:/src/util/torTools.py This abstraction should make arm reasonably easy to move to stem. Also, stem's getting many of that wrapper's features so arm's codebase could be greatly simplified after we move. * Port TorBEL TorBEL would be a great candidate after we work out most of stem's rough edges by moving arm. It'll likely provide some interesting use cases, though this is still a ways out. ======= Usability ======= Stem doesn't yet have a site, nor have I posted its sphinx documentation anywhere. A few things that we should do here is... * Make a pretty site Ideally I'd like to write the site itself with sphinx so we have a consistent look between the front page and the documentation. * Site with auto-updating documentation This would involve setting up a site with a cron process that fetches stem and, if changed, serves up the new documentation. * Tidy up sphinx docs Stem has a lot of documentation, but we haven't really looked much at the sphinx output with an eye for making it developer friendly. It would be nice to have people try to use stem, and improve the documentation for the confusing bits. * Examples We should ask tor-dev@ for a list of bite sized Tor tasks that people commonly want (like "print my relay's bandwidth" or "list all of the relays with the BadExit flag"). Then write example scripts that do this, and provide them on stem's site to give example usage. > If so, how hard is it to set up a dev environment? Very, very easy. Assuming that you have python, git, and tor installed simply do the following. * Get a copy of stem git clone git://git.torproject.org/stem.git * To run its unit tests cd stem ./run_tests.py --unit * To run its integ tests ./run_tests.py --integ > Does the Tor Project have a formal mentorship program? How does that work? I'm not sure what you mean by a 'formal mentorship program'. I've mentored students through GSoC and Wesleyan's open source program if that answers your question. Cheers! -Damian

2 1

torrouter development
by ficus＠robocracy.org 12 Sep '12

12 Sep '12

Hello tor-dev! I would like to contribute to the torouter (aka TorRouter, aka OnionBox?) project, with the intention of getting a "functional" development image for the DreamPlug hardware released in the next few weeks. The goals of the torouter project seem a bit vague (especially w/r/t a transparent torified WiFi access point), perhaps this is why development slowed down previously. I will attempt a design document and specification, but mostly focus on making the core components (debian, tor, web interface) functional and configurable, such that they could be leveraged by others as solutions to specific use cases. Will this be useful to others? It seems like the preferred collaboration tool is the trac wiki and tickets. Many of the torouter tickets seem stale and incomplete, and the roadmap on the trac wiki is very out of date. Unless there is advice i'll ignore those but continue discussion on tickets like #3854 (Summary of outstanding things with Torouter) and #3453 (Torouter desires and features). cheers!

4 9

Format-Transforming Encryption for Censorship Circumvention
by Kevin P Dyer 11 Sep '12

11 Sep '12

Following my email to this list, dated 29/07/2012, I direct your attention to the IACR eprint document http://eprint.iacr.org/2012/494, "Format-Transforming Encryption: More than Meets the DPI". In it, we present our framework for steganographic encoding of messages using regular languages, along with initial findings for a Python/C++ based implementation. To briefly highlight some of the main things we deliver: * A record-layer, powered by format-transforming encryption, that can tunnel arbitrary SOCKS streams. * Algorithms that allow efficient and invertible mapping between bit strings and elements of a regular language L. These allow us to encode traditional encryptions of plaintexts into strings from L in a way that maximizes the number of bits that are encoded. * A framework for the creation of good regular languages, "good" with respect to performance and security. In particular, our language-learning framework produces sets of regular expressions (compact representations of the languages) that are learned from real traffic. Our system also allows you to use off-the-shelf regular expressions, like those from appid [1] and l7-filter [2] that are designed to detect HTTP traffic. We consider this preliminary technical report on a work-in-progress. In fact, we can already do more than what is reported (e.g. greater variety of languages, better system performance), but we will save these advances for a future release. Cheers, Kevin P Dyer (and his co-authors) [1] http://code.google.com/p/appid/ [2] http://l7-filter.sourceforge.net/

2 3

Integration of Tor, Tor Browser, Tor IM, Tor Birdy, Vidalia, Tor Router, Tails, etc.
by adrelanos 10 Sep '12

10 Sep '12

Hello, the current integration has a lot open issues and feature requests. [2] Because there might come a proposal [1] to solve this cleanly, I created an overview of all related open issues. [2] There are just so many issues I though it makes sense to create an overview so nothing gets forgotten. Feel free to edit/correct/expand the wiki site. Add your wishes. I cc'ed all effected people, if someone has been forgotten, feel free to forward this mail. Can we have this discussion on tor-dev? Cheers, adrelanos [1] https://trac.torproject.org/projects/tor/ticket/5611#comment:43 [2] https://trac.torproject.org/projects/tor/wiki/doc/TB

2 1

[GSoC] [Stegotorus] Code submission and more curl
by vmon 10 Sep '12

10 Sep '12

Hello Zack, 1) I would like to ask your permission to submit the whole code for code submission. First because my task in the summer wasn't only to write the parts that I wrote but also to read the code and debug it as well. Secondly because the git log shows who wrote what. Thirdly, It's easier. 2) I had more discussion on libcurl-dev with the libcurl main developer. He thinks despite the fact my approach is working right now, it isn't stable and can break down in a different environment. To solve this, I'm going to let curl also read from the socket instead of libevent, this isn't very hard (I'll disable both EV_READ and EV_WRITE as soon as I'm handing the socket to curl). I confirmed with Nick that (unlike libcurl) libevent support this. 3) Thank you for telling me about fts. I'm going to replace boost code with fts soon. 4) >I still don't see the problem. If you do exactly that, and don't use >he DECLARE macros for http_apache_steg, what breaks? If I don't use the DECLARE then I can't specify http_apache as the steg protocol in the command line . Best, vmon

4 4

Tenative schedule for Tor 0.2.4 [Or, why I might reject your patches in November->March]
by Nick Mathewson 07 Sep '12

07 Sep '12

Hi, all! Last year, I announced a tenative schedule for 0.2.3.x. We didn't stick to it, and things have gone a little pear-shaped with getting 0.2.3.x stabilized, but I think with a few tweaks we can use something similar to get a good schedule out for 0.2.4.x. My goals remain about what they were before: get release out faster by getting better at saying "no" to features after a release window. My target is March or April 2013. To that end: 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. November 10, 2012: Big feature checkpoint. If I don't know about a large feature by this date, it might have to wait. November 10, 2012: Big feature proposal freeze. Any small feature which requires a design proposal must have its design proposal finished by this date. December 10, 2012: Big feature merge freeze. No big features will be merged after this date. December 10, 2012: Small feature proposal freeze. Any small feature which requires a design proposal must have its design proposal finished by this date. January 10, 2013: Feature merge freeze. No features after this date. I mean it. Feb 20, 2013: Buggy feature backout date. Any feature which seems intractably buggy by this date may be disabled, deprecated, or removed until the next release. On the meaning of "feature": I'm probably going to argue that some things that you think are bugfixes are features. I'm probably going to argue that your security bugfix is actually a security feature. I'm probably even going to argue that most non-regression bugfixes are features. Let's try to get a release out *early* in 2013 this time, come heck or high water. (This is all subject to change, but let's not push it.) [0] https://lists.torproject.org/pipermail/tor-dev/2011-July/002851.html happy hacking, -- Nick

4 4

Parallel release series for directory authorities?
by Nick Mathewson 06 Sep '12

06 Sep '12

Hi, all! Here's an idea I had for directory authorities and the 0.2.3 release series. "As you know Bob," Tor 0.2.3 will be stable very soon, and I'm hoping not to take any more patches for it except for important security issues. I want 0.2.4 to come out very early next year. But in the meantime, to support 0.2.4, and to deploy security/reliability features to the network early, there are some directory consensus features that we'd want to deploy before the rest of 0.2.4 is done and stable. In particular, I'd like directories to be able to reach consensus on IPv6 addresses (6363), and I'd like to try out the code that Mike wrote to make the bandwidth voting system more robust against dishonest during its startup phase (2286). So here's my plan: Make a "maint-0.2.3-da" branch based on 0.2.3, plus feature patches for directory authorities. It gets patches from the stable series (0.2.3), plus directory-authority features under development. It would get merged-forward into 0.2.4, to make sure that 0.2.3-da and 0.2.4 behavior stay in sync. This way we can get new authority features working in time to support 0.2.4 clients, but without forcing too many authorities to run 0.2.4 before it's ready, and without forcing us to make feature changes in 0.2.3 proper. Thoughts? yrs, -- Nick

7 8

(FWD) Re: known attacks on Tor
by Roger Dingledine 05 Sep '12

05 Sep '12

Hi folks, Here's an email I wrote to a researcher who is working on categorizing anonymity attacks. I figured I should share it with you in case it's useful in some way. It's also related to my talk at https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/program.html and I expect to use it as background for my discussions at the upcoming Dagstuhl: http://www.dagstuhl.de/no_cache/en/program/calendar/semhp/?semnr=12381 --Roger ----- Forwarded message from Roger Dingledine <arma(a)mit.edu> ----- > If you have any suggestions about which paper on each attack is most > likely to provide such an explanation, please send them to me as soon > as possible. > > > - "Traffic confirmation attack". If he can see/measure the traffic flow > > between the user and the Tor network, and also the traffic flow between > > the Tor network and the destination, he can realize that the two flows > > correspond to the same circuit: > > http://freehaven.net/anonbib/#SS03 > > http://freehaven.net/anonbib/#timing-fc2004 > > http://freehaven.net/anonbib/#danezis:pet2004 > > http://freehaven.net/anonbib/#ShWa-Timing06 > > http://freehaven.net/anonbib/#murdoch-pet2007 > > http://freehaven.net/anonbib/#ccs2008:wang > > http://freehaven.net/anonbib/#active-pet2010 It depends in what way you want to become more precise. I think the #SS03 paper might have the simplest version of the attack ("count up the number of packets you see on each end"). The #timing-fc2004 paper introduces the notion of a sliding window of counts on each side. The #murdoch-pet2007 one looks at how much statistical similarity you can notice between the flows when you are only sampling a small fraction of packets on each side. > > - "Congestion attack". An adversary can send traffic through nodes or > > links in the network, then try to detect whether the user's traffic > > flow slows down: > > http://freehaven.net/anonbib/#torta05 > > http://freehaven.net/anonbib/#torspinISC08 > > http://freehaven.net/anonbib/#congestion-longpaths Section 2 and the first part of Section 3 in #congestion-longpaths is probably your best bet here. It actually provides a good pretty overview of related work including the passive correlation attacks above. If by 'more precise' you mean you want to know exactly what the threat model is for this attack, I'm afraid it varies by paper. In #torta05 they assume the adversary runs the website, and when the target user starts to fetch a large file, they congest (DoS) relays one at a time until they see the download slow down. In #congestion-longpaths they assume the adversary runs the exit relay as well, so they know the middle relay, and the only question is which relay is the guard (first) relay. In #torspinISC08 on the other hand, they preemptively try to DoS the whole network except the malicious relays, so the target user will end up using malicious relays for her circuit. > > - "Latency or throughput fingerprinting". While congestion attacks > > by themselves typically just learn what relays the user picked (but > > don't break anonymity as defined above), they can be combined with > > other attacks: > > http://freehaven.net/anonbib/#tissec-latency-leak > > http://freehaven.net/anonbib/#ccs2011-stealthy > > http://freehaven.net/anonbib/#tcp-tor-pets12 These are three separate attacks. In #tissec-latency-leak, they assume the above congestion attacks work great to identify Alice's path, and then the attacker builds a parallel circuit using the same path, finds out the latency from them to the (adversary-controlled) website that Alice went to, and then subtracts out to find the latency between Alice and the first hop. #ccs2011-stealthy actually proposes a variety of variations on these attacks. They show that if Alice uses two streams on the same circuit, the two websites she visits can use throughput fingerprinting to realize they're the same circuit. They also show that by looking at the throughput Alice gets from her circuit, you can rule out a lot of relays that wouldn't have been able to provide that throughput at that time. And finally, they show that if you build test circuits through the network and then compare the throughput your test circuit gets with the throughput Alice gets, you can guess whether your circuit shares a bottleneck relay with Alice's circuit. Where "show" should probably be in quotes, since it probably works sometimes and not other times, and nobody has explored how robust the attack is. #tcp-tor-pets12 has the adversary watching Alice's local network, and wanting to know whether she visited a certain website. The adversary exploits vulnerabilities in TCP's window design to spoof RST packets between every exit relay and the website in question. If they do it right, the connection between the exit relay and the website cuts its TCP congestion window in response, leading to a drop in throughput on the flow between the Tor network and Alice. In theory. It also works in the lab, sometimes. I also left out http://freehaven.net/anonbib/date.html#esorics10-bandwidth which uses a novel remote bandwidth estimation algorithm to try to estimate whether various physical Internet links have less bandwidth when Alice is fetching her file. In theory this lets them walk back towards Alice, one traceroute-style hop at a time. In practice they need an Internet routing map (these are notoriously messy for the same reasons the Decoy Routing people are realizing), and also Alice's flows have to be quite high throughput for a long time. > > - "Website fingerprinting". If the adversary can watch the user's > > connection into the Tor network, and also has a database of traces of > > what the user looks like while visiting each of a variety of pages, > > and the user's destination page is in the database, then in some cases > > the attacker can guess the page she's going to: > > http://freehaven.net/anonbib/#hintz02 > > http://freehaven.net/anonbib/#TrafHTTP > > http://freehaven.net/anonbib/#pet05-bissias > > http://freehaven.net/anonbib/#Liberatore:2006 > > http://freehaven.net/anonbib/#ccsw09-fingerprinting > > http://freehaven.net/anonbib/#wpes11-panchenko > > http://freehaven.net/anonbib/#oakland2012-peekaboo #oakland2012-peekaboo aims to be a survey paper for the topic, so it's probably the right one to look at first. > > - "Correlating bridge availability with client activity." > > http://freehaven.net/anonbib/#wpes09-bridge-attack If you run a relay and also use it as a client, the fact that the adversary can route traffic through you lets him learn about your client activity. Section 1.1 summarizes: 2. A bridge always accepts connections when its operator is using Tor. Because of this, an attacker can compile a list of times when a given operator was either possibly or certainly not using Tor, by repeatedly attempting to connect to the bridge. This list can be used to eliminate bridge operators as candidates for the originator of a series of connections exiting Tor. We demonstrate empirically that typically, a small set of linkable connections is sufficient to eliminate all but a few bridges as likely originators. 3. Traffic to and from clients connected to a bridge interferes with traffic to and from a bridge operator. We demonstrate empirically that this makes it possible to test via a circuit-clogging attack [17, 15] which of a small number of bridge operators is connecting to a malicious server over Tor. Combined with the previous two observations, this means that any bridge operator that connects several times, via Tor, to a web-site that can link users across visits could be identified by the site's operator. > > I tried to keep this list of "excepts" as small as possible so it's not > > overwhelming, but I think the odds are very high that if the ratpac comes > > up with other issues, I'll be able to point to papers on anonbib that > > discuss these issues too. For example, these two papers are interesting: > > http://freehaven.net/anonbib/#ccs07-doa Traditionally, we calculate the risk that Alice's circuit is controlled by the adversary as the chance that she chooses a bad first hop and a bad last hop. They're assumed to be independent. But if an adversary's relay is chosen anywhere in the circuit yet he *doesn't* have both the first and last hop, he should tear down the circuit, forcing Alice to make a new one and roll the dice again. Longer path lengths (once thought to make the circuit safer) *increase* vulnerability to this attack. I think the guard node design helps here, but whether that's true is an area of active research. > > http://freehaven.net/anonbib/#bauer:wpes2007 If you lie about your bandwidth, you can get more traffic than you "should" get based on bandwidth investment. In theory we've solved this by doing active bandwidth measurement: https://blog.torproject.org/blog/torflow-node-capacity-integrity-and-reliab… but in practice it's not fully solved: https://trac.torproject.org/projects/tor/ticket/2286 --Roger ----- End forwarded message -----

1 0