tor-dev

tor-dev@lists.torproject.org

3581 discussions

Re: [tor-dev] [tor-relays] [warn] No unused circIDs found on channel without wide circID support
by ra 29 Sep '14

29 Sep '14

reply-to: tor-dev On Monday 29 September 2014 15:00:29 tor-admin wrote: > since upgrading torland to 0.2.5.8-rc I see the below warnings. Is this > something to worry about? IMHO this might be due to a programming error in the circuit ID selection code or possibly indicate a DoS attack. > -------------------------------------------------------------------------- > Sep 28 16:07:24.000 [warn] No unused circIDs found on channel without wide > circID support, with 0 inbound and 4 outbound circuits. Found 0 circuit IDs > in use by circuits, and 64 with pending destroy cells. (0 of those were > marked bogusly.) The ones with pending destroy cells have been marked > unusable for an average of 7594 seconds and a maximum of 16137 seconds. > This channel is 18469 seconds old. Failing a circuit. > Sep 28 16:07:24.000 [warn] Circuitmux on this channel has 4 circuits, of > which 4 are active. It says it has 29535 destroy cells queued. Those lines are important. I would suggest opening a ticket on trac. See #11553. Best, Robert

1 0

Re: [tor-dev] Scaling tor for a global population
by teor 28 Sep '14

28 Sep '14

On 27 Sep 2014, at 10:18 , tor-dev-request(a)lists.torproject.org wrote: > Date: Fri, 26 Sep 2014 17:18:07 -0700 > From: Mike Perry <mikeperry(a)torproject.org> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Scaling tor for a global population > > 2. Cut off relays below the median capacity, and turn them into bridges. > > Relays in the top 10% of the network are 164 times faster than > relays in the 50-60% range, 1400 times faster than relays in the > 70-80% range, and 35000 times faster than relays in the 90-100% range. > > In fact, many relays are so slow that they provide less bytes to the > network than it costs to tell all of our users about them. There > should be a sweet spot where we can set this cutoff such that the > overhead from directory activity balances the loss of capacity from > these relays, as a function of userbase size. > > Result: ~2X reduction in consensus and directory size. Do these extra relays function as spare (albeit slower) capacity in the network? If so, we'd have to be careful to set the cut-off low enough that any spikes in usage could be accommodated. Also, doesn't reducing the number of routers in the consensus risk harming network diversity? I understand that if these routers are a net burden on the network, then they're not actually contributing much to diversity overall. But what about users with obscure configurations like "New Zealand routers only", or "custom list of 20 trusted routers"? (Is a restricted set of routers a common enough use case?) Do we risk pulling the data they need from the consensus? Then again, users with these sorts of configurations are probably technically savvy enough to fix any issues that occur with any changeover. T teor pgp 0xABFED1AC hkp://pgp.mit.edu/ http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

1 0

Re: [tor-dev] Scaling tor for a global population
by Ryan Carboni 28 Sep '14

28 Sep '14

> > But, because this is fraction rises with both D and U, these research > papers rightly point out that you can't keep adding relays *and* users > and expect Tor to scale. Broadcast a fraction of all available directories? Use md5 as a random number generator, hash the ECC/RSA keys using md5. A user connecting to the network will generate an 8-bit random value, and based on that, will download one of 1/256 directories. Right now, any relay with more than ~100Mbit of capacity really > needs to run an additional tor relay instance on that link to make > use of it. If they have AES-NI, this might go up to 300Mbit. Any plans to use ChaCha8 instead of AES? It would an order of magnitude faster. It is also unlikely for ChaCha8 to become sufficiently insecure to effect web-size non-video traffic.

1 0

obfs4 test bundles
by Yawning Angel 26 Sep '14

26 Sep '14

Hello all, So after a brief pause in my productivity due to the dev meeting and some IRL things, I'm back in the swing of development and have been working on getting obfs4 ready for development. I've recently mostly finished a fairly large cleanup/refactor of the obfs4 codebase and dusted off the Tor Browser build integration patch. Test bundles signed with my PGP key are available at: https://people.torproject.org/~yawning/volatile/tor-browser-obfs4-20140820/ Some quick notes: * The bundles are alpha. DO NOT USE THEM IF YOU REQUIRE STRONG ANONYMITY OR SECURITY. * While it is possible to pull out the obfs4proxy binary from the bundle and use it to run a bridge, that will be a *terrible* idea because the bundles are missing some logging related fixes. * The Windows and OSX bundles are entirely untested, because I do not have access to either platform. The Linux bundle appears to work. * Using obfs2/obfs3 will also exercise new code (obfs4proxy instead of obfsproxy). * I'm not uploading a 32 bit linux bundle for now. * The one obfs4 test bridge is mine, and is the one I posted to tor-dev@ (port is different, bridge parameters are the same). If you wish to follow obfs4 deployment the bug associated with this task is #12130. Questions, comments, feedback welcome. -- Yawning Angel

1 2

Pluggable transports meeting today (16:00UTC Wednesday 24th of September 2014)
by George Kadianakis 24 Sep '14

24 Sep '14

Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur today at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. As you see, the meeting day was recently changed from Fridays to Wednesdays: https://lists.torproject.org/pipermail/tor-dev/2014-August/007317.html Thanks for your attention!

2 1

Making and distributing custom TBB with a new "home-page"
by Fabio Pietrosanti (naif) 23 Sep '14

23 Sep '14

Hi all, for a very interesting deployment of GlobaLeaks in the are of Human Rights defense, we will have the need to distribute a customized Tor Browser Bundle to the sources. The "customization" requirement is simple: Have as a default home-page the GlobaLeaks .onion site . We must go that way because: - the "target country" where the sources are cannot download TBB due to torproject.org being censored - the sources are absolutely non-technologically savy (average 60yo lawyers doing human rights defense) The website where there will be the leaking instructions and the download of such custom TBB will be "privately distributed" trough word of mouth and trusted connections, with no public solicitation. So we must do some piece of software that will: - Download TBB in specific languages (2-3 specific languages) for each platform - Unpack TBB (in all formats for Windows, OSX, Linux) - Apply the customization (set the home-page, with slightly different parameters depending on the language) - Check periodically if a new version is available and, in that case, re-execute the process described above to release updated version of TBB The questions are: a) Which is a simple/stable/resilient way to check which is the latest version of TBB b) Does someone have already done that kind of customization-process? c) Can everything be done from Linux, like a cron-job, in a fully automatic way? d) Which other customization / ideas / concern are there regarding this process? I'd personally love if the customization would enable me to completely disable the "URL Bar" and all of the Browser Button in order to make it useful only to use it as a console to send information being a source, without the possibility to go browse other sites. Waiting for comments before writing some quick specs -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org

3 4

meek on Microsoft Azure
by David Fifield 22 Sep '14

22 Sep '14

I've got meek working on Microsoft Azure, a cloud services platform and CDN. If you'd like to try it, use a 4.0-alpha bundle and enter the bridge line: Bridge meek 0.0.2.0:3 url=https://az668014.vo.msecnd.net/ front=ajax.aspnetcdn.com As usual, the IP address is ignored; I'm just assigning incrementing numbers in the port. az668014.vo.msecnd.net is a CDN domain that points to meek-reflect.azurewebsites.net, where the service is really running. The front domain ajax.aspnetcdn.com is one that hosts a bunch of common web libraries: http://www.asp.net/ajax/cdn. I didn't look very hard to see if there are other good front domains. More information on Azure: https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure David Fifield

1 0

Attack linking Tor circuits
by Otto Huhta 19 Sep '14

19 Sep '14

Dear Tor developers, We’ve been working on an MSc Thesis project looking into an attack that links different Tor circuits back to the same user, using only information available to a Tor middle node. We’ve discovered that an adversary can quite accurately determine if two consecutive circuits are used by the same user just by looking at when these circuits are built and destroyed or when they begin and stop relaying traffic. This is mainly the result of the fixed 10 minute circuit lifetime and the fact that the transition to using a new circuit is quite sharp. According to our measurements, circuits belonging to the same user are built at very close to 10 minute intervals. Also, when one circuit stops relaying traffic another one suddenly becomes active, at almost the very same moment. Thanks to these properties we could train a classifier to quite efficiently identify matching pairs of circuits (9% EER). We looked into the threat posed by this attack to Tor users and concluded that because of entry guards the threat is real, given that an adversary can control a significant portion of middle node traffic. Finding matches among all possible Tor circuits would result in too many false positives but thanks to entry guards an adversary can focus only on circuits built through these specific nodes and quite efficiently determine if two circuits belong to the same user. Possible plans of moving to using only a single guard node make the situation much more severe: we concluded that for a user picking a slow guard node, the adversary can find almost all circuits belonging to a same user (again assuming control of a large portion of middle node bandwidth). We thus see that before moving on with any such plans, one should consider the effect of our findings on the threat posed by a middle node linking user circuits. As a final note, we considered the effects of randomizing the circuit lifetime (e.g. between 5-15 minutes) to mitigate this threat but concluded that it would not necessarily solve the problem. The most prominent feature linking two circuits together seems to be the time difference between traffic ending on one circuit and beginning on another circuit, and this link cannot be broken by varying the circuit lifetime. However, if someone were to devise such a modification, we would be happy to re-run our tests to see what kind of an effect this would have on the success rate of an adversary. For those interested in our findings, the full thesis Linking Tor Circuits can be found at: http://www0.cs.ucl.ac.uk/staff/G.Danezis/students/Huhta14-UCL-Msc.pdf Best regards, Otto Huhta, UCL

2 3

Responsible disclosure
by Bram de Boer 18 Sep '14

18 Sep '14

Hi, How can I responsibly report a bug that might affect security (e.g. possibility to DoS Tor nodes)? I searched the torproject.org website, but couldn't find any pointers with respect to responsible disclosure. Do I just file a trac ticket and/or drop it in this mailinglist? Do I report it directly to some of the key players in this project (Roger, Nick, etc.)? Thanks, Bram

3 2

Reminder OONI dev meeting happening tomorrow
by Arturo Filastò 18 Sep '14

18 Sep '14

Hi Oonitarians, This is a reminder to inform you that tomorrow (Friday 19th of September) there will the weekly dev meeting. It happens on IRC (irc.oftc.net) on the channel #ooni at 17:00 CET (15:00 UTC). Everyone is invited! See you tomorrow! ~ Art.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev