tor-dev February 2016

tor-dev@lists.torproject.org

44 participants
58 discussions

Support for mix integration research
by Katharina Kohls 25 Feb '16

25 Feb '16

Hi everyone, we are a team of 4 PHD students in the field of IT security, working at the Ruhr-University Bochum at the chair for systems security and the information security group. Currently we work on a research project with the goal to leverage the security of Tor against timing attacks by integrating mixes in Tor nodes. The general idea is to differentiate high-latency and low-latency traffic among the network for applying additional delays to the former type of packets. Based on this the success of traffic analysis attacks should be decreased without restricting the low latency assurance of Tor. We plan to integrate the mix into Tor version 0.2.5.10 and analyze its performance along with the Shadow simulator. As there are a lot of details to consider, both regarding the technical aspects of the integration as well as practical assumptions, e.g., "how do we get DiffServ-like nodes?", we would be pleased to receive some feedback on the idea and support for the implementation of the mix. Further details on the mix and stuff will sure be provided if needed! Cheers, Katharina -- M.Sc. Katharina Kohls Ruhr-University Bochum Research Group Information Security Universitätsstrasse 150 ID 2/123 44780 Bochum / Germany Phone: +49 234 / 32 - 26991 Web: www.infsec.rub.de

4 4

Nyx Project Ideas
by Damian Johnson 25 Feb '16

25 Feb '16

Hi wonderful relay operators. It's GSoC season again, where students can be funded to make open source projects like Tor even better! Nyx (previously known as arm [1]) has been my main focus this last year and is inching ever closer to release. For those unfamiliar with it, Nyx is an ncurses monitor for Tor relays providing a bandwidth graph, event log, connections, config editor, and more. Rather than add new features my work has focused on making Nyx simpler and faster, but GSoC provides us an opportunity to do even more. So I'm curious - what do you want from an ncurses monitor? The answer may be 'keep it simple'. Feature creep does us no favors. But if there's a good fit I'd love to mentor a project that makes your lives even better! I'm not overly fond of the ideas I've had so far... * Windows support. This poses a few challenges. [2] * When running multiple tor instances on a single system connect to them all, aggregating the information. So anything come to mind? Cheers! -Damian [1] https://www.atagar.com/arm/ [2] https://trac.torproject.org/projects/tor/wiki/doc/arm#Windows

1 0

Tor consensus documents now in a public append-only verifiable log
by Linus Nordberg 24 Feb '16

24 Feb '16

Hi, One of the directory authoritites (maatuska) is submitting new consensus documents to a public append-only verifiable log, similar to what Certificate Transparency uses. If you think this is exciting and want to help out with this experiment, consider setting up a monitor and start looking for anomalies, or at least an auditor verifying proper log behaviour. Or help making the submission code in Tor more useful (f.ex. submitting to the log's .onion address, submitting votes too, making the POST chunked). Below are two examples of how to investigate what's in the log so far. Fetching one document, using curl --------------------------------- Here's an example of how to fetch the 80th entry in the log: $ curl -sA '' -x socks4a://localhost:9050/ 'http://mvkhztpvqcxpdbn3.onion/open/gaol/v1/get-entries?start=79&end=79' The result is a large JSON document (~740kB): --8<---------------cut here---------------start------------->8--- { "entries" : [ { "leaf_input" : "AAAAAAFTA+pimwAACHcGH4sIAAAAAAACA+y96XLi2rYu+H8/hX7WDTKN+sa [...] rUcfehxefa/xjpqq45E6dZEPzPosd1cg8mSGi03G/r+LikK1rl7GQ/I7yOzvfvGm3jeWrD/g6++f2yN9oeI7dH+31/w3O7wS+HI8YAAAA", "extra_data" : "AAAA" } ] } --8<---------------cut here---------------end--------------->8--- "leaf_input" contains a gziped, base64 encoded Tor consensus document. Note that this format _will_ change in the future! Fetching all documents, using fetchallblobs.py from catlfish ------------------------------------------------------------ Given a local copy of branch gaol6 of catlfish in my private repo [1] and a copy of the public key for the log [2], here's how to download all the entries from the log and store them in ZIP files in directory 'gaol-store': $ torsocks catlfish/tools/fetchallblobs.py --store gaol-store --publickey logs gaol.ct.nordu.net.pem http://mvkhztpvqcxpdbn3.onion/ The base64 encoded entry can be extracted using this awk script: /-----END BLOB-----/{blob=0} //{if (blob) print} /-----BEGIN BLOB-----/{blob=1} Feeding that to base64 -d and gzip -d should produce a Tor consensus document. For example: $ cat 00000080 | awk '/-----END BLOB-----/{blob=0}//{if (blob) print}/-----BEGIN BLOB-----/{blob=1}'| base64 -d | gzip -d [1] $ git clone -b gaol6 https://git.nordu.net/user/linus/catlfish.git [2] https://www.ct.nordu.net/gaol.ct.nordu.net.pem https://www.ct.nordu.net/gaol.ct.nordu.net.pem.asc

1 0

Post-quantum symetric crypto
by Jeff Burdges 22 Feb '16

22 Feb '16

Symmetric crypto might start worrying more about being post-quantum soon : http://arxiv.org/abs/1602.05973 Best, Jeff

1 0

Help with TOR on UDP/QUIC
by Xiaofan Li 20 Feb '16

20 Feb '16

Hi everyone: I'm new to Tor dev community and my name is Xiaofan Li, currently a senior at Carnegie Mellon University studying ECE and CS. My friend Kevin Ku and I are taking a graduate class <http://www.cs.cmu.edu/%7Esrini/15-744/S16/> on computer networks and we decided to examine the possibilities of substituting TCP with the Google QUIC protocol for Tor in order to improve performance. We are emailing you because: 1. We want to get some points of contact with the Tor community in case of future integration and/or testing. 2. We want to know if *anyone else* has done (or is doing) Tor with QUIC. If so, what their status is; and if not, why not? 3. We want to get *your opinions* on this idea. Attached is our (very) preliminary plan and goals for the project. Any feedback is welcomed. 4. Any *implementation recommendations*. My plan is to find a clean layer of abstraction where I can substitute TCP with QUIC. Any ideas? On a first look, I'm thinking about either *or/channel.c* or *or/transports.c * 5. Any *testing suggestions*? How do Tor engineers test new stuff? Please take a look at our outline attached below. Thank you! Looking forward to hearing from you soon! Li.

3 3

Summary of meek's costs moved to tor-project list
by David Fifield 20 Feb '16

20 Feb '16

I decided to move the meek cost emails to the tor-project list, because they are more project-y than dev-y. Here is the email for January 2016: https://lists.torproject.org/pipermail/tor-project/2016-February/000101.html There's a table of all previous summaries here: https://trac.torproject.org/projects/tor/wiki/doc/meek#Costs

1 0

Analysis of ASan usage
by Jens Kubieziel 18 Feb '16

18 Feb '16

Hi, FYI: oss-security lately had a posting with the title »Address Sanitizer local root« (<URL:http://www.openwall.com/lists/oss-security/2016/02/17/9>) The author showed that building a suid binary with ASan enables local root exploits. He also shows some other problems with this approach. In his posting he mentions the Tor Browser and recommends to not use the word »hardened«, because it is misleading. -- Jens Kubieziel http://www.kubieziel.de Vielleicht verdirbt Geld tatsächlich den Charakter. Auf keinen Fall aber macht ein Mangel an Geld ihn besser. Jonathan Swift

1 0

Last network team/dev meetings of February: Wednesday and Friday and Monday!
by Nick Mathewson 17 Feb '16

17 Feb '16

Hi, all! Wednesday Feb 17 morning at 0830 EST (==1330 UTC) is the regular Tor/Network team development meeting. Friday Feb 19 at 0900 EST (==1400 UTC) is the discussion meeting for proposals 257 and 258. Monday Feb 22 at 2000 EST (==Tuesday at 0100 UTC) is the secondary meeting for folks who find the Wednesday meetings totally inconvenient. I'll try not to be asleep this time! We'll be skipping online meetings Feb 24 through Mar 2, since many people will be traveling. Or meeting face-to-face! We've been scheduling things on https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Meeting… . So far, it's been working well! peace to all, -- Nick

1 0

Two major improvements to the Tor Metrics back-end
by Karsten Loesing 15 Feb '16

15 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, as some of you may have noticed, Tor Metrics had some trouble updating its aggregate data lately, and the issues there are by no means completely gone now. But I managed to tweak two of the aggregations that previously took many hours. Here's a graph: https://people.torproject.org/~karsten/volatile/metrics-modules-2016-01-07.… The green dots at the end are from the latest update. Changes affecting the 70-run-hidserv-stats.sh module: https://gitweb.torproject.org/metrics-web.git/commit/?id=c0f4c76 https://gitweb.torproject.org/metrics-web.git/commit/?id=6054ddd Changes affecting the 80-run-clients-stats.sh module: https://gitweb.torproject.org/metrics-web.git/commit/?id=44acfe5 Boom! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWjprFAAoJEJD5dJfVqbCrPT0IALX6dNrL3PK2gbbwAGmm4OBg 4kuz7qFMshTNFp8iT6HB5H9G9/wldgAPanZn+zLlFM0sOBoY1d16RoL2+ay+VKXQ xTeY85tgqMAnbaS2lQcBRZy5j8RXPui94g/ZcKnw9Bg3TpwLFO2+cMXqh1nhMLtb V+Lj0EE+y7qjdtOQO/IbOQzeUr/S9xtze44dRkGlZ0NmeKQsHXaR3m8w8ReIP32k vZekymZkUgbfzYeRoB+jI+3M3l0CF5agwIelhhHlnWwkJ70jPPVrAGX3rhb8X9SX iSNMUJTG62AC3WLqdRkhyY2YJ5OHSMLtpvQwOaOzqSs1yHWylHDVSLTZx+XCQmM= =tvfK -----END PGP SIGNATURE-----

3 4

Re: [tor-dev] Existing Tor Guard Selection Algorithm
by George Kadianakis 15 Feb '16

15 Feb '16

Reinaldo Junior <rjunior(a)thoughtworks.com> writes: > On Thu, Feb 11, 2016 at 7:55 AM, George Kadianakis <desnacked(a)riseup.net> > wrote: > >> Chelsea Komlo <ckomlo(a)thoughtworks.com> writes: >> >> > Hi George, >> > >> > Thanks for your help with this! >> > >> > We wrote up our high-level understanding of the current Tor guard >> selection >> > algorithm here: >> > >> > https://gist.github.com/chelseakomlo/2acbe15314b5a809c6f4 >> > >> > This has more than our python simulation, but less than the actual Tor >> > implementation. For example, it is missing conditions like prioritization >> > by uptime, capacity, etc. >> > >> > >> https://github.com/twstrike/tor_guardsim/blob/develop/lib/original_client.py >> > >> > If you wouldn't mind taking a look at this and letting us know anything >> > that is missing/should change, that would be really helpful. >> > >> >> Your pseudocode looks pretty accurate based on what I remember from the >> guard >> algorithm and from quickly skimming the code. >> >> One inaccuracy might be that if IIRC in RECEIVE_NEW_CONSENSUS we don't >> remove >> guards that are not listed in the latest consensus. Instead we mark them >> as 'bad' >> which rules them out of retries etc. till they reappear on the consensus. >> See entry_guard_set_status() and its caller for how this works. >> > > <snip> > > See: > https://github.com/twstrike/tor_guardsim/commit/1fb7400c0c8e167508753ede15b… Hmm, looks pretty good! One note: I feel that you are hiding information behind the simple phrase "Build LIVE_GUARDS". Interesting things happen in populate_live_entry_guards() that are not documented by your algo. For example, in entry_is_live() we call entry_is_time_to_retry(), which periodically retries guards based on time: struct guard_retry_period_s periods[] = { { 6*60*60, 60*60 }, /* For first 6 hrs., retry hourly; */ { 3*24*60*60, 4*60*60 }, /* Then retry every 4 hrs. until the 3-day mark; */ { 7*24*60*60, 18*60*60 }, /* After 3 days, retry every 18 hours until 1 week mark. */ { TIME_MAX, 36*60*60 } /* After 1 week, retry every 36 hours. */ }; Also, another function that I'm not sure if you have seen (and whether it fits with the algorithm) is entries_retry_all(). BTW, I like the way you have splitted the algo into various events (RECEIVE_NEW_CONSENSUS, BUILD_NEW_CIRCUIT, CHOOSE_A_GUARD, CONNECT_ENTRY_GUARD, etc.). We should maybe try to shape Ola's new algorithm to fit this event structure exactly since it resembles the actual Tor networking API. Cheers!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev February 2016