- tor-dev - lists.torproject.org

onionoo.tpo hardly reachable
by nusenu 24 May '17

24 May '17

Hi Karsten, onionoo is hardly reachable since about 17 hours ago. Is this only externally facing or will this also cause onionoo to miss descriptors internally? Any ETA on when this will improve? thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 10

txtorcon 0.19.3
by meejah 24 May '17

24 May '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fixing another regression, 0.19.3 causes txtorcon to (once again) correctly work with SocksPort lines containing unix socket options when used with txtorcon.connect(). Thas bug was introduced in 0.19.0 which reduced the number of GETINFO and GETCONF calls (to help filtering-proxies). You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.19.3 https://github.com/meejah/txtorcon/releases/tag/v0.19.3 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.19.3.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.19.3.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 f73396667909a3c7a98f4dd865edf4ed6a2518ee5a935d92e18b8a479ec244fd txtorcon-0.19.3.tar.gz e0901f7743a43ed6389f0de31c1f547d89b32723a5ae9316d6cae9ad8eacdbea txtorcon-0.19.3-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZJTJVAAoJEMJgKAMSgGmn5woIAIyFRa7NhSNm/zMMJE92jtgA C3UY55q3FF4VycC7K77EkaudHPMqlr9MA3EeGkx4NVu0KAX7lIT4GFCsZTlnOdXm rglZ7FFYh49KoAWSMGCMJ7LlauYUitXptynte3lWcqbvjGJkCqMd6WuXslTooSI2 68gq/aoTbXoHWNg1C6DtBhR0JqvN+Vq7ARHyqc4bDloh1LXAvEUwsbKvDtrpXTbe eRwMlKTKoUXhXjxO37NtoNSxT6HUFNcOFOYcLnWtBMPty9W90xY2wC1LbWwYymbY Pk97OUceSyoHxAGsBYjKCdTXEWB6TO5lmHE3+t48OqiYt4ELAWkJFUBf5d6Mnto= =ZRcE -----END PGP SIGNATURE-----

1 0

Further New Hope Improvements
by bancfc＠openmailbox.org 24 May '17

24 May '17

New paper released a week ago makes further improvements on New Hope, reducing decryption failure rates, ciphertext size and amount of entropy needed. This new version will be submitted as a NIST PQ competition candidate. https://eprint.iacr.org/2017/424

2 1

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

Re: [tor-dev] blacklisting relays with end-to-end correlation capabilities?
by Sebastian Hahn 09 May '17

09 May '17

Dear all, below mail was meant to make it to tor-dev, but I got a bounce and didn't notice until now. Whoops, my apologies. > On 8. Dec 2016, at 14:29, Sebastian Hahn <tor(a)sebastianhahn.net> wrote: > > Hi, > >> On 08 Dec 2016, at 14:03, nusenu <nusenu(a)openmailbox.org> wrote: >> >> Dear tor directory authorities, >> >> TLDR: Would you blacklist relays with end-to-end correlation capabilities? >> >> I'm asking to find out whether it makes sense to put any effort into >> finding such operators [2]. If most dir auths would not blacklist such >> relays than it does not make sense to look for them I guess. >> >> So please let us know whats your opinion on that - thank you. >> >> >> More information below and there [1]: >> >> >> The process could look something like this: >> >> - someone identifies such a relay groups (basically based on contactinfo >> [2]) >> - contact the operators asking to fix this (ideally this would be a >> @torproject.org sender) >> - give them 15 days to fix it >> - if not fixed: blacklist respective guard relays >> - give them the possibility to get removed from the blacklist once fixed > > I do not think that this is worthwhile. It establishes a precedent where > setting your contact info is something that gets you banned, potentially > incorrectly because it's unauthenticated, whereas we're unable to identify > people who actually maliciously run several relays without such indicators. > > Additionally, it's yet one more thing to update the dirauths' configs > for, but with rather more overhead as we might get multiple mails back > and forth about how MyFamily is annoying to maintain, how they're just > trying to help, etc. All not so bad arguments. > > If we did this, also why would we blacklist the nonexit relays? That > seems to not make sense, as a relay operator could have multiple relays > that act as guard and exit simultaneously. I think we'd need to > blacklist at least all the exit relays, if not all of them. BadExiting > them would then be the more sensible choice. Scarcity of resources has > in the past led us to bad designs like Valid/Invalid relays etc, which > causes way more annoyances than good things. > > Cheers > Sebastian Cheers Sebastian

1 0

Re: [tor-dev] [tor-commits] [tor/master] Bug 17592: Clean up connection timeout logic.
by Roger Dingledine 09 May '17

09 May '17

On Mon, May 08, 2017 at 06:00:18PM +0000, nickm(a)torproject.org wrote: > commit d5a151a06788c28ac1c50398c6e571d484774f47 > Author: Mike Perry <mikeperry-git(a)torproject.org> > Date: Tue Feb 21 21:28:00 2017 -0500 [...] > + - Increase the intial circuit build timeout testing frequency, to help > + ensure that ReducedConnectionPadding clients finish learning a timeout > + before their orconn would expire. The initial testing rate was set back > + in the days of TAP and before the Tor Browser updater, when we had to be > + much more careful about new clients making lots of circuits. With this > + change, a circuit build time is learned in about 15-20 minutes, instead > + of ~100-120 minutes. Fyi, the current Tor network has "cbttestfreq=60" set in its consensus params. Is this something we should change? --Roger

2 1

Chutney Default: DNS or Offline?
by teor 07 May '17

07 May '17

Dear chutney users, Do you use DNS with chutney? (Chutney uses IP addresses by default.) Chutney has never worked offline, because Tor Exits check DNS before publishing their exit policy. And if DNS fails while a test is being run, chutney fails. (See Tor bug #21900.) We can make chutney work offline by disabling DNS. See the chutney bug at: https://trac.torproject.org/projects/tor/ticket/21903 But we need to decide what the default is: Do you want chutney to work offline by default? Or do you want chutney to have working DNS by default? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

making sure I configure OutboundBindAddressExit correctly
by nusenu 05 May '17

05 May '17

Hi, since I really like this new feature I added [1] initial autoconfiguration support for it to ansible-relayor (user can opt-in via a single boolean and we automate the rest). I want to make sure I do this correctly and would like your feedback on the following questions: a) Is 'OutboundBindAddressOR' in the following context optional (in the sense that it does not change tor's behavior)? ExitRelay 1 ExitPolicy reject *:25,accept *:* ORPort 1.2.3.4:9001 OutboundBindAddress 1.2.3.4 OutboundBindAddressOR 1.2.3.4 OutboundBindAddressExit 7.7.7.7 is identical to: ExitRelay 1 ExitPolicy reject *:25,accept *:* ORPort 1.2.3.4:9001 OutboundBindAddress 1.2.3.4 OutboundBindAddressExit 7.7.7.7 (since according to the manual page OutboundBindAddress*OR* would just override OutboundBindAddress, which is not needed in the above example since they match) b) Is it ok to set OutboundBindAddressExit for IPv4 only, even if we set 'IPv6Exit 1' or is setting an IPv6 OutboundBindAddressExit address required after setting OutboundBindAddressExit for IPv4? Since this question might be a bit confusing I'll give an example in form of torrc lines: ORPort 1.2.3.4:9001 OutboundBindAddress 1.2.3.4 OutboundBindAddressExit 7.7.7.7 IPv6Exit 1 ExitRelay 1 ExitPolicy reject *:25,accept *:* (this config has an IPv4 OutboundBindAddressExit entry but no IPv6 OutboundBindAddressExit entry) c) Similar to (b) is it ok to enable OutboundBindAddressExit for IPv6 only? d) Is it ok if multiple tor instances on the same host use the same OutboundBindAddressExit address? (ignoring the fact that big exits might run out of source ports?) thanks, nusenu [1] https://github.com/nusenu/ansible-relayor/commit/00fa7c571e8b6f6256092d9928… -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 2

Leekspin and Stem descriptor creation
by Damian Johnson 02 May '17

02 May '17

Hi Isis. For kicks and giggles this weekend I added the ability for Stem to create descriptors... https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#can-i-… https://gitweb.torproject.org/stem.git/commit/?id=b2a54ad This is something Stem has always been able to do but it was buried in our testing helpers. Now descriptor subclasses have a static create() and content() method. This *doesn't* yet support signing descriptors. I'm looking into that next. To that end I took a peek today at leekspin (https://pypi.python.org/pypi/leekspin) and... damn. Beautiful work! Besides the crypto are there any other aspects of your library you think we should incorporate? Cheers! -Damian

1 0

Prop279 and DNS
by Jeremy Rand 29 Apr '17

29 Apr '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! Maybe this topic has already been brought up, but in case it hasn't, I'll do so. I notice that Prop279 (onion naming API) defines its own API rather than using DNS. I guess that this is because of security concerns about the centralization of the DNS. However, in case you're unaware, Namecoin is designed to interoperate with DNS. Let's say that, hypothetically, Tor defined a DNS-based naming system for onion services, where "_tor.example.com" had a TXT record that was verified with DNSSEC in order to make Tor direct "example.com" to whatever that TXT record had. If this were done, Namecoin would be able to produce the necessary TXT record and DNSSEC signatures, via the standard DNS protocol, using an authoritative nameserver that runs on localhost. (The DNSSEC keys used would be unique per user, generated on installation.) Indeed, this is how we're planning to interoperate with non-proxy-based Internet applications. My guess is that it would be a lot less work on Namecoin's end if such a system were used with Tor rather than a separate naming API. It's unclear to me how this would affect other naming systems such as GNS (does GNS interoperate with clients that use DNS?), and it's also unclear to me whether this would produce extra work for the Tor developers (maybe DNS adds extra attack surface that would need to be mitigated somehow, or maybe there would be complexity in implementing stream isolation?). Anyway, just figured I'd bring up the topic so that everyone's on the same page regarding figuring out whether it's a good idea. Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with PGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY4rf2AAoJELPy0WV4bWVwviQP+wSz9/L8czef+L+viSIIrrtv BOp32fysFWw1HijQ/42IoELPhkkzsHjek4IuW6Hn3VHGYs9vJ+rQ9aOcCMGNGD/f f7ktcw3upH/UHiFPp2S0LeNqaoup8qvUQxG/AeP5R20gD/660ZXuIVl4uOaOu5HJ IaghO9ZpzSF695H97hf7bz3H3Wrmch8tjC+FZ+SwWdgqGa4ijjZbTvkypcPEZ6YI YQ22PmoQQWQBbe9JLujLa46PwRWU+UKsppmQYi7dY9K7aO7/J9eKQnOLkUWtdKrN WjtJMV+V4oL/g4IiJrPs5n82pGSvpFi/dMrakoGq2w+v1dJolz/lSGUj7+sWVQZl iqoq6c+l7MjKNynmj/Yn8IquhhwRmVAj4sjV+2jUeVmAf/tHDCBsDYvIDcDeIblu j6y9e7ePTlMTpuxbZ7OKJjsWgGF5+yumWHPtJYs9uBoATeYDM6+Gxm73rDZxRVCl +KGN1jMuREA9N1ZiWuK/ueeeZWGHii4L4UWvdK0qriSvc0HxaQeCGlovEDfO8btO ZDfq9P6USEZywqFyzjzvOUwxnhihwNMdFiSt0RfxLuX34H6POvFYHhw85ESlliY8 0RPjHW6GZywNuOgpYDu9kPS6HPFhXUtok708Jmc926ctX2TT0CJlK6Fl3R2kZGCa nOLHLSYVmkehj6u3RdBf =Hz3g -----END PGP SIGNATURE-----

5 7

Tor Tech Report 2017-04-001 available
by iwakeh 28 Apr '17

28 Apr '17

Hi there! A new Tor Tech Report is available [0]: "Privacy analysis of Tor's in-memory statistics." Abstract: "This report analyzes which possibly sensitive, potentially personally identifying data is stored in memory of Tor relays and bridges or reported to the directory authorities and makes suggestions to reduce the collection and temporary storage of such data." The report addresses concerns regarding metrics collection about the Tor network that were often raised and discussed in the community. Many topics can only be briefly touched in the scope of such a report. Thus, there is quite some work in thinking, writing, and coding open to be done. Based on the report's suggestions the Metrics Team plans the following steps (mainly in May and June 2017): * Distill a change proposal for Tor server changes that address the most pressing of the identified issues. * Code the Tor server patches according to the proposal. * And, provide necessary patches for Tor Metrics products concerned by the changes for Tor servers. Future plans for the months after that are to assess privacy questions as raised in this report more in-depth and describe statistical accuracy throughout the data-verse of Tor Metrics. Many thanks to Aaron Johnson, Paul Syverson, Rob Jansen, and Tim Wilson-Brown, who gave very valuable feedback to ideas and questions we asked during the Amsterdam meeting! Also many thanks to Karsten Loesing, who collected the feedback in Amsterdam, patiently answered all questions about the details of Tor and Tor Metrics, and reviewed the report! Cheers! iwakeh [0] https://research.torproject.org/techreports/privacy-in-memory-2017-04-28.pdf

1 0

txtorcon 0.19.0
by meejah 26 Apr '17

26 Apr '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very happy to release txtorcon 0.19.0. This merges most of the development that happened over the last several months on the release-1.x branch. Featuring: * Full Python3 support (and universal wheels) * Drop txsocksx and use a custom implementation (this also implements the custom Tor SOCKS5 methods RESOLVE and RESOLVE_PTR). Uses Automat for the state-machine. * Drop support for older Twisted releases (12, 13 and 14 are no longer supported). * Add a top-level API object (txtorcon.Tor) that abstracts a running Tor. Instances of this class are created with txtorcon.connect or txtorcon.launch. These instances are intended to be "the" high-level API and most users shouldn't need anything else. * Integrated support for twisted.web.client.Agent, baked into txtorcon.Tor. This allows simple, straightforward use of treq or "raw" twisted.web.client for making client-type Web requests via Tor. Automatically handles configuration of SOCKS ports. * new high-level API for putting streams on specific Circuits. This adds txtorcon.Circuit.stream_via and txtorcon.Circuit.web_agent methods that work the same as the "Tor" equivalent methods except they use a specific circuit. This makes txtorcon.TorState.set_attacher the "low-level" / "expert" interface. Most users should only need the new API. * big revamp / re-write of the documentation, including the new Programming Guide: https://txtorcon.readthedocs.io/en/latest/guide.html * Issue 203: https://github.com/meejah/txtorcon/issues/203 * new helper: txtorcon.Router.get_onionoo_details which downloads JSON for a particular relay from OnionOO * new helper: txtorcon.util.create_tbb_web_headers which returns headers resembling a recent Tor Browser suitable for use with Twisted or treq web agents. * Issue 72: https://github.com/meejah/txtorcon/issues/72 * Specific SocksError subclasses for all the available SOCKS5 errors added by https://github.com/felipedau * (more) Python3 fixes from https://github.com/rodrigc You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.19.0 https://github.com/meejah/txtorcon/releases/tag/v0.19.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.19.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.19.0.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 09d56fbd6e33eef7405c8ca354bbba06da2cefa02763d15c4bc9ac274c5daeeb dist/txtorcon-0.19.0.tar.gz cc51b4249ad126c31ea2746ec5ef1bcb7f6b0c34ced070913ed7772c0e48edf5 dist/txtorcon-0.19.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJY+ZjOAAoJEMJgKAMSgGmnadEH/R0YCoID3xTkbFL7mVhtqY2e p7sPcFT50jUGDASaER2YoQ4syzptnQcLid5/pCf+F2xMwCVgayqaipNXtugNHZIl 9cCOnI09+IntCFLkVXQqMGnEzSSzcM0Ln87Qa9MMjNNZM+aj2WshmFnObdqsWNRo tIhnuKgMDgqoO9OgiXCsUXFQeooDDidnrnJgl5U7AA0+13nIar+/q9vCxMtDqSV9 kfh5IkB4RaeJTzDtTMYQKKHTIltdn7o0LrCyp1QsMhX+iHU4xZVOi7etgFnACqsP S1u2LMT1FggvyEAzIwn45ADhKpuPBrR35N5C21vQklHVEb9nQxI9LXTHCi0Fv5g= =mGZj -----END PGP SIGNATURE-----

1 1

Tor 0.3.1 ticket triage: please do this today if you hack on Tor.
by Nick Mathewson 26 Apr '17

26 Apr '17

Hi! We've got 3 weeks left in the 0.3.1 merge window (which closes on May 15) so let's try to triage the tickets. Here's what to do if you are going to develop anything for Tor 0.3.1: - Make sure that everything you are going to do for 031 is assigned to you, in the 0.3.1 milestone, and has a points estimate. ("Points" is a rough "how many days will this take me?" guess.) - If there is anything assigned to you for 031 that you _won't_ be doing for May 15, or that you won't be doing at all, please unassign it and/or defer it from the 031-milestone. - If your total points estimate is over 12 or so (or whatever number of programming days you think you will have, please defer the less important things, or tag them with 031-stretch. Then, in 24 hours or so, for all the tickets that don't get an owner, I will either defer them or mark them "too important to defer" and look for somebody else to do them. Let's see how this works! -- Nick

2 1

Action items wrt ed25519 onion address verification in prop224 (was Re: [tor-project] Network team meetings notes from 17 April 2017)
by George Kadianakis 25 Apr '17

25 Apr '17

Ian Goldberg <tor(a)cypherpunks.ca> writes: > On Thu, Apr 20, 2017 at 03:40:58PM +0300, George Kadianakis wrote: >> Hey Ian, >> >> so the current problem with ed25519-donna is that when I'm doing the >> above, I'm getting the following 32-byte key after ge25519_pack(). Here >> it is hexed up: >> >> 0x0100000000000000000000000000000000000000000000000000000000000000 >> >> I don't see any methods in ed25519-donna for checking a point or a >> packed point to see if it's the point at infinity (identity element). > > There actually is such a function, but it's buried in a weird place. > ge25519_is_neutral_vartime in ed25519-donna-batchverify.h does what you > want, but it's static, so you would need to copy it (and remove the line > involving batch_point_buffer). Probably not worthwhile. > > I can easily believe the representation of the identity (neutral) > element in ed25519 is the hex value above. (And it is; see below.) > >> I've been assuming that the point at infinity would be an all-zeroes >> 32-byte array, because that's what we are doing in curve25519, but I >> actually have no idea how the array representation of ge25519_pack() >> works. Here is our process for curve25519: >> https://gitweb.torproject.org/tor.git/tree/src/common/crypto_curve25519.c#n… > > Curve25519 only outputs the x coordinate, which is indeed 0, so you get > the all-zero value. ed25519 outputs the y coordinate (which is the > 255-bit value 0x000...0001 in little-endian format) and the single-bit > parity of the x coordinate (which is 0), so you do get the hex you give > above. (The identity element is the point (0,1) in Edwards curves, not > actually the point at infinity.) > >> The above packed point is an all zeroes 32-byte string, apart from the >> very first bit which is set. Could it be that the first bit is the >> compressed sign of the 'x' coordinate or something, and that's actually >> the point at infinity? >> >> But then what's the right way to check for the point at infinity? Check >> that everything is 0 apart from the first sign bit? > > Yes, pack the point, and compare it to the above 32-byte value. > >> And after I figure this out, I need to do the same for the reference >> implementation of ed25519, because as it seems Tor uses two simultaneous >> implementations of ed25519: >> https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519 > > Yes, hopefully that implementation packs points in the same way! > >> Thanks for the help Ian :) Very much appreciated! > > No worries. > [CCing tor-dev since people might find it interesting] Thanks for the advice Ian :) With your help, I have now implemented the validation check. Check out the ticket #22006 and the branch `bug22006` here: https://gitweb.torproject.org/user/asn/tor.git/commit/?h=bug22006&id=628dd1… One last thing I'd like to do here is test our validation function against a pubkey with torsion component to make sure that it gets rejected. How would you go about generating such a pubkey? I was thinking of using the CRT to find an integer a \in Z, s.t a == 0 (mod l) && a == 1 (mod 8) but then I didn't know how to go from that scalar with a torsion component to an ed25519 point... Cheers!

2 4

Experimental Namecoin naming for Tor
by Jeremy Rand 23 Apr '17

23 Apr '17

Hi, I've pushed some experimental code for using Namecoin naming in Tor. The code is at https://github.com/JeremyRand/OnioNS-client , you want the "namecoin" branch. Rough instructions: 1. Install Namecoin Core and let it fully download the blockchain. (SPV support is in the works.) 2. Enable JSON-RPC with user/password authentication in Namecoin Core. (The procedure is identical as in Bitcoin Core.) 3. Set your Namecoin Core JSON-RPC login info in the init_namecoind function of src/assets/onions-stem.py. 4. Start Tor Browser Bundle. 5. Run src/assets/onions-stem.py. 6. The first time you run it, it will instruct you to add a line to one of the Tor config files; do this. Specifically, it will ask you to add the line "__LeaveStreamsUnattached 1" to torrc-defaults. 7. Start Tor Browser Bundle again. 8. Run src/assets/onions-stem.py again. 9. Try opening a Namecoin website in Tor Browser. Example websites that I've verified to work include: http://duckduckgo-onion.bit.onion http://bitcoinpl.bit http://federalistpapers.bit.onion http://botball.bit (gives a Dreamhost error) The .bit.onion sites should also work as plain .bit. Semantically, .bit.onion means that it will always resolve to a .onion address (meaning that .bit.onion names are encrypted and authenticated regardless of whether TLS is used); .bit means that it will resolve to any of .onion, IPv6, IPv4, or CNAME (prioritized in that order), meaning that .bit names are only encrypted and authenticated if TLS is used. These semantics are open to revision later, as the Tor community evolves its canonical naming semantics. This is all proof of concept for now; some or all of this code will be rewritten later (hopefully to use the pluggable naming API instead of the control port). It will probably not work with Whonix/Tails/Subgraph due to the control port filter. It will definitely make your Tor Browser instance stand out, since most users can't resolve Namecoin domain names. And since it accesses the control port, it could presumably do lots of horrible things to your Tor instance (and I make no guarantees that it's properly sanitizing the input that's passed to Tor's control port). Huge thanks to Jesse for OnioNS (on which this code is based), and also thanks to Nick for sharing helpful info on this mailing list. Let me know how it works for you. Cheers, -- -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment.

2 1

Provisional Draft of Hyphae
by isis agora lovecruft 21 Apr '17

21 Apr '17

Hello! Henry and I have written up a provisional draft design for a social bridge distribution scheme, modelled after rBridge, which we're calling Hyphae. For those further interested, here is a draft PDF. [0] Included within is: - A technical history, with primary sources, of censorship of the Tor network, as well as remediations for those censorship attempts; - A description of the bridge distribution problem, including orthogonal problems and solutions, and prior proposals specific to the bridge distribution; - A description of an algebraic-MAC attribute-based credential scheme, requisite non-interactive zero-knowledge proofs, and sub-credentials and tokens, which we use to build our bridge distribution protocol; - A centralised, anonymous micropayments scheme, which we hope is of interest to other projects (such as Brave); - A description of our Hyphae protocol; - An high-level, cryptographic and protocol design comparison to the rBridge protocol; and - Draft notes on our implementation. Please note that this is a provisional draft paper, containing the design but not yet containing results specific to our implementation. We expect some things to change in minor ways during further refinement and implementation. That said, we welcome all feedback and appreciate review. [0]: https://patternsinthevoid.net/hyphae/hyphae.pdf Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

1 0