May 2017 - tor-dev - lists.torproject.org

Latest draft policy on handling tor security issues
by Nick Mathewson 23 May '17

23 May '17

Hi, all! I put this on the wiki, but I think it should have more attention. https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Securit… It's the draft policy that we're using to guide our action when we run into security issues in the program "tor". It's not finalized, but we've been trying to follow it as we notice issues in order to identify any problems in it. It's had some review already, but more is always welcome. Have a look! -- Nick

1 0

Tomorrow (5/23) is a core-tor trac-attack day!
by Nick Mathewson 22 May '17

22 May '17

Hi! At our meeting just now, the network team discussed our needs for a more organized set of trac tickets about past and previous versions. (This is about tickets against Tor itself, though if you want to jump in on some other component, you're welcome to do so!) So, tomorrow, I'm planning to spend (nearly?) all my work hours on #tor-dev, working on organizing trac tickets. And more help is always welcome! Drop by and say hi and help us clean out our bugtracker! Areas of interest will be: * Wrapping up tickets that are associated with older release milestones * Trying to make sure all current-milestone tickets get owners * Making sure 0.3.2.x is not just a dumping ground for "things we didn't get around to doing in 0.3.1.x." * Improving the accuracy of the "easy" keyword by applying it to more tickets and removing it from any that weren't so easy after all. * Looking for a way to get the "Tor: Unspecified" milestone under control. I'm likeliest to be around during 1230-1800 UTC and 2230-0000 UTC. best wishes, -- Nick

1 0

Clarifications on guard-spec.txt
by Roger Dingledine 19 May '17

19 May '17

Hi folks! I'm catching up on my proposals, and I really like guard-spec.txt. Nicely done! I made some fixes that I hope are straightforward: https://lists.torproject.org/pipermail/tor-commits/2017-May/122942.html https://lists.torproject.org/pipermail/tor-commits/2017-May/122948.html https://lists.torproject.org/pipermail/tor-commits/2017-May/122986.html And I have four remaining questions/topics that could use some feedback from the spec authors/implementors rather than just having me bust in and change things. --------------------------------------------------------------- A) We don't really say what we mean by "adding" a guard to an ordered list. In particular: > We add new members to {CONFIRMED_GUARDS} when we mark a circuit > built through a guard as "for user traffic." When we say "add", do we mean "append" here? > To compute primary guards, take the ordered intersection of > {CONFIRMED_GUARDS} and {FILTERED_GUARDS}, and take the first > {N_PRIMARY_GUARDS} elements. If there are fewer than > {N_PRIMARY_GUARDS} elements, add additional elements to > PRIMARY_GUARDS chosen _uniformly_ at random from > ({FILTERED_GUARDS} - {CONFIRMED_GUARDS}). Similarly, does "add" mean "append"? > Once an element has been added to {PRIMARY_GUARDS}, we do not remove it > until it is replaced by some element from {CONFIRMED_GUARDS}. Confirmed > elements always proceed unconfirmed ones in the {PRIMARY_GUARDS} list. This one looks like a bug as currently stated: by "proceed", do we mean "precede"? --------------------------------------------------------------- B) In Sec 4.10, whenever we get a new consensus, we: > For every guard in {SAMPLED_GUARDS}, we update {IS_LISTED} and > {FIRST_UNLISTED_AT}. In the old design, we also believed the Running flag in the new consensus, that is, we marked the guards as reachable again. It looks from sampled_guards_update_from_consensus() like we no longer do that. Is that old behavior considered a bug and we intentionally stopped, or did we not consider it? I am ok with "that was stupid behavior, so we stopped", but if we didn't know that we used to do it, maybe we should decide whether it is stupid behavior. :) --------------------------------------------------------------- C) In Sec A.4, in the state file we have > "bridge_addr" -- If the guard is a bridge, its configured > address and OR port. Optional. How does this play with bridges that have pluggable transports? In my "bridge obfs2 128.31.0.34:51715" line, the ORPort of the bridge is not listed. It looks from https://trac.torproject.org/projects/tor/ticket/21027 like we did some fixing here, but the spec didn't get an update? --------------------------------------------------------------- D) In Sec 4.8, when a circuit succeeds: > * If this circuit was <usable_if_no_better_guard>, it is now > <waiting_for retry>. You may not yet attach streams to it. > Then check whether the {last_time_on_internet} is more than > {INTERNET_LIKELY_DOWN_INTERVAL} seconds ago: > > * If it is, then mark all {PRIMARY_GUARDS} as "maybe" > reachable. > > * If it is not, update the list of waiting circuits. (See > [UPDATE_WAITING] below) [Where INTERNET_LIKELY_DOWN_INTERVAL has been picked as 10 minutes.] To make sure I understand this one, consider the following scenario: * We go offline, and our current circuits fail. * We try to make new circuits through each of our primary guards, failing for each (because we're offline) and marking them down. * Then we move to the remaining confirmed+usable ones, and mark those down too. * Then we work through the rest of USABLE_FILTERED_GUARDS, marking them down too. As we mark them down, USABLE_FILTERED_GUARDS shrinks, causing us to add new elements to SAMPLED_GUARDS to replenish USABLE_FILTERED_GUARDS. * After we've brought SAMPLED GUARDS to 60, we stop adding new ones. At this point, we are out of tries: > * Otherwise, if USABLE_FILTERED_GUARDS is empty, we have exhausted > all the sampled guards. In this case we proceed by marking all guards > as <maybe> reachable so that we can keep on sampling. Does this mean that we mark our *already-sampled* guards as reachable, thus making USABLE_FILTERED_GUARDS big again, and we loop through the above steps again, and we keep looping until we come back online? The above "so that we can keep on sampling" phrase confuses me, because it seems like there's no way that we would arrive at "USABLE_FILTERED_GUARDS is empty" without also having SAMPLED_GUARDS at its maximum size: > Whenever we are going to sample from {USABLE_FILTERED_GUARDS}, > and it contains fewer than {MIN_FILTERED_SAMPLE} elements, we > add new elements to {SAMPLED_GUARDS} until one of the following > is true: > > * {USABLE_FILTERED_GUARDS} is large enough, > OR > * {SAMPLED_GUARDS} is at its maximum size. So, perhaps we mean "so that we can keep on trying circuits"? Or, oh! Do we mean "sampling from USABLE_FILTERED_GUARDS", not "sampling from GUARDS"? Ok, proceeding with my scenario: let's further say that we're offline in such a way that we get quick failures for the connect attempts, so we burn through each connect attempt at one per second, meaning we blow through our CONFIRMED set within the first 10 minutes of going offline. Let's also say we come back online within those 10 minutes. A circuit (to some guard in SAMPLED_GUARDS) succeeds, and the circuit is now of type <waiting_for_better_guard>. Since last_time_on_internet isn't very long ago, and there aren't any other circuits open, the new circuit becomes <complete>, and we mark this new guard as CONFIRMED, and stick it on the end of the CONFIRMED set. We keep using the newly CONFIRMED guard (since it's the only one we think is reachable) for about a half hour, at which point the PRIMARY_GUARDS_RETRY_SCHED schedule makes us forgive our primary guards, and we switch back to our favorite primary guard. Do I have it right? Thanks! --Roger

3 3

Simulating how Laplace noise added to directory-request statistics would affect user number estimates
by Karsten Loesing 19 May '17

19 May '17

Hi everyone, we'd like to improve directory-request statistics by obfuscating values on relays before they are reported to the directory authorities. A possible obfuscation method is to add Laplace noise to request counts for all ~250 countries, so that it's unclear whether a request was actually made by a user or is just noise. In fact, we did a similar thing to onion service statistics two years ago. But before we do this we need to find out whether obfuscated values would still be useful enough to estimate user numbers in the Tor network. We ran a simulation using archived descriptors and put our results including a graph, CSV files, and simulation code on this wiki page: https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/Obfusca… The result is that we can't just go ahead and put in this noise, because we'd have to improve our user number estimation algorithms first. Otherwise we might risk losing one of our most important statistics: the number of daily Tor users by country. If you have any thoughts on these results or want to help make the simulation more accurate, please let us know! All the best, Karsten (for the metrics team)

1 0

[release] metrics-lib/DescripTor 1.7.0
by iwakeh 17 May '17

17 May '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! During the next time several releases of metrics-lib/DescripTor are planned culminating in a major release around the end of June. The first of this series is 1.7.0: https://dist.torproject.org/descriptor/1.7.0/ - From the change-log: * Medium changes - Parse "padding-counts" lines in extra-info descriptors [0]. - Some bug fixes avoiding dropped content - and test improvements. for details see [1]. Please direct comments and questions to the metrics-team mailing list [2]. Cheers, iwakeh [0] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1160 [1] https://gitweb.torproject.org/metrics-lib.git/plain/CHANGELOG.md?id=6941084… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZHD24AAoJEPeEx9Sa/gvi8f4P/AgD8VU99oifrGT9z7GKJgwS +dAb9ba14MpT0Jk1/RuP8CQQgsoV2AcqcDI1xsOpmR9nbIEbxGmAJxCsu8IxoC9L 0n1gvdIo7034yEPPv4vI+AI+KnS4KgHJAhpOcCPKsbeHsjSqCHRpphyJehkm53os dhFPRuQWmyHJ7pvN5R6HIJJ7htluzyt+zhz9XNhdyQ4OrNSgl/M76PAMRfeJt3WX 0e2eOeGk92zXxv+fYtUbTsrr6UwjQkR7Nx4qW49tqKyLy/0CDdHUnFmmYnrddOAs b0ZMpKzRCN8cKPXxFedV/uKD5eNNy//p1w/WAKeuKONGXogNKHsxxrnQ68CuEypx OTVq8cI4XPX62hMw61P9HhepCHzj3LPjhZ8t19IZ0jAguT2ESh2R0UkTO/v9Ul33 DwiJd3U1yWxYyKGGIJg988jk8KNUiM83aoyclriGFwUwolxbD+pBmmZicGRnR031 xOzP+f6Q0v/RnJG4GyydF+X+B2RO6/bllM9YDogWAwoj7DGS1CAP8/YEorkCQXg+ RBLsaZIXjRh0uPpanao6iL6xX+yBzu35ihRhLKNusX6bDubiA95Mr0F4OoDzj4sa 9d3wWX2OyGXQmfS+tVrLCtOQn1CkkLOVYo9G+DDomouhgzUM/TBAefy2IMz0IeJS ioVzKXE2IC4UTX1Y7sWh =pe7s -----END PGP SIGNATURE-----

1 0

(no subject)
by harshit tandon 15 May '17

15 May '17

I would like to contribute to tor browser how can I help regards, Harshit

3 2

Re: [tor-dev] Feedback Extension for Tor Browser
by Jayati Dev 13 May '17

13 May '17

Hello, The feedback extension project is not a part of GSoC this year, but I was wondering if its still possible to help with the project, if someone isn't already working on it? Thanks, Jayati > On 11-May-2017, at 5:30 PM, "tor-dev-request(a)lists.torproject.org" <tor-dev-request(a)lists.torproject.org> wrote: > > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. man page: MyFamily (nusenu) > 2. Re: man page: MyFamily (nusenu) > 3. Re: man page: MyFamily (teor) > 4. Re: man page: MyFamily (nusenu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 10 May 2017 21:30:00 +0000 > From: nusenu <nusenu-lists(a)riseup.net> > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] man page: MyFamily > Message-ID: <65cc7527-0dff-fa55-5442-0f1ba7fe1b7c(a)riseup.net> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I wanted to help improve the man page section for MyFamily in the light > of today's MyFamily change [1]. > > I sometimes contact relay operators about their MyFamily configuration > and a common request is: "Please send me an example" > > So I added an example to the man page (including the new multiline > support in 031) > > - replaced "node" with "fingerprint" > (no one is using nicknames anymore, or onionoo does not display > fingerprints?) Are nicknames still supported? (Roger started to remove > remaining bits of the past Named "world" so this might be another place?) > - made clear that you can still have multiple fingerprints in a single > line (if this will be deprecated at some point I can add a deprecation info) > - added info that the fingerprint can be prefixed with $ > - changed "This option can be repeated many times, for multiple families" > to > "This option can be repeated many times, for multiple fingerprints" > (from one relay's view there is only one family) > > nusenu > > inline patch below (I can paste it to trac if you like) > > [1] > https://gitweb.torproject.org/tor.git/commit/?id=d76cffda601eed40d6a81eadb1… > https://trac.torproject.org/projects/tor/ticket/4998#comment:11 > > 1735c1735 > < [[MyFamily]] **MyFamily** __node__:: > --- >> [[MyFamily]] **MyFamily** __fingerprint__,__fingerprint__,__...__:: > 1738,1739c1738,1741 > < their identity fingerprints. This option can be repeated many > times, for > < multiple families. When two servers both declare that they are in the > --- >> their (possibly $-prefixed) identity fingerprints. >> This option can be repeated many times, for >> multiple fingerprints, all fingerprints in all MyFamily lines will > be merged. >> When two servers both declare that they are in the > 1745,1746c1747,1753 > < When listing a node, it's better to list it by fingerprint than by > < nickname: fingerprints are more reliable. > --- >> Example: + >> MyFamily > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB > + >> MyFamily CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC + >> + >> is identical to: + >> + >> MyFamily > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC > > >

1 0

txtorcon 0.19.2
by meejah 12 May '17

12 May '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fixing two more problems with the 0.19.1 release, I hereby give you version 0.19.2 which adds: * Work around a bug in "incremental" library (Issue 233) * Fix for Issue 190 from Felipe Dau * add txtorcon.Circuit.when_built You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.19.2 https://github.com/meejah/txtorcon/releases/tag/v0.19.2 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.19.2.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.19.2.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check c0e05ff4878468474167536a7b30edec23ae69eb26869c3e9ed9878e63ddc882 dist/txtorcon-0.19.2.tar.gz 0e2e85424c8f4c4627066ceebee59a931300e3712007f0a7620791729c80d459 dist/txtorcon-0.19.2-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZFSkrAAoJEMJgKAMSgGmnlwYIAIc2mFs0tQngDVYauEdg+WTD 0TMDGpXoQTFXgAj2st6MA+UITgc1od3PveIeNkYi7bCYxGndQbZeGJ14itXTwTZR lce9jHkn2ZG7LHhqcqC1Zdzp1+6lHQSgT81tPYzfUXhrqUHWjJjEHlSjAllZDD4E zbV9y8zdSuQYK65VqFPnGl4BzOKBAL3VEwrtzf2wYejykodZsXp5Aygl7WAmuSXv bl5avMfp0GLAu+5XvpfAqdAUQimtSE5/ODIWogF1Emqvu19qIwspQJk81A3yUSCa wD22S3BQc8RuE9GSjk75ykA8fYAfv8n1fYSqbaJazR7fe9ZMRsNPcwEiyF86jlw= =cZ/A -----END PGP SIGNATURE-----

1 0

Which network simulator are you using/suggesting for testing Tor
by vmon 11 May '17

11 May '17

Hello Tor-devers, A friend of mine wants to simulate Tor and measure the network performance by tweaking various node selection heuristics etc. He was wondering what simulator usually people who perform and study Tor uses. This was the best he came up with https://shadow.github.io/ but was wondering if anyone has a better suggestion. Thanks a lot for your help, vmon

2 1

man page: MyFamily
by nusenu 11 May '17

11 May '17

Hi, I wanted to help improve the man page section for MyFamily in the light of today's MyFamily change [1]. I sometimes contact relay operators about their MyFamily configuration and a common request is: "Please send me an example" So I added an example to the man page (including the new multiline support in 031) - replaced "node" with "fingerprint" (no one is using nicknames anymore, or onionoo does not display fingerprints?) Are nicknames still supported? (Roger started to remove remaining bits of the past Named "world" so this might be another place?) - made clear that you can still have multiple fingerprints in a single line (if this will be deprecated at some point I can add a deprecation info) - added info that the fingerprint can be prefixed with $ - changed "This option can be repeated many times, for multiple families" to "This option can be repeated many times, for multiple fingerprints" (from one relay's view there is only one family) nusenu inline patch below (I can paste it to trac if you like) [1] https://gitweb.torproject.org/tor.git/commit/?id=d76cffda601eed40d6a81eadb1… https://trac.torproject.org/projects/tor/ticket/4998#comment:11 1735c1735 < [[MyFamily]] **MyFamily** __node__:: --- > [[MyFamily]] **MyFamily** __fingerprint__,__fingerprint__,__...__:: 1738,1739c1738,1741 < their identity fingerprints. This option can be repeated many times, for < multiple families. When two servers both declare that they are in the --- > their (possibly $-prefixed) identity fingerprints. > This option can be repeated many times, for > multiple fingerprints, all fingerprints in all MyFamily lines will be merged. > When two servers both declare that they are in the 1745,1746c1747,1753 < When listing a node, it's better to list it by fingerprint than by < nickname: fingerprints are more reliable. --- > Example: + > MyFamily AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB + > MyFamily CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC + > + > is identical to: + > + > MyFamily AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

2 3