- tor-project - lists.torproject.org

Make it harder to brute-force Trac user passwords
by Jens Kubieziel 08 Aug '17

08 Aug '17

Hi, recently I had a discussion with GeKo about brute-forcing trac accounts. Someone reported that trac allows to test username/password combinations without having an upper limit. This resulted in https://trac.torproject.org/projects/tor/ticket/23120 and I set the the maximum amount to 17 (chosen arbitrarily). When an account is locked an admin has to unlock it. However I received some mails who raised the point that people can now lock out legitimate users quite easily. Thatswhy I want to discusss this here. What happens when people sucessfully guess a password? In general people can create an account or use the cypherpunks account to gain more permissions. So it doesn't make sense to guess those passwords. However it gets more interesting when someone guesses the password of a member of the TRAC_ADMIN group. Then the attacker can read our configuration and create some havoc. However with the current setup it is hardly possible to change trac.ini. Even TRAC_ADMIN has not the permissions to do so. So we lived with this risk in the last years and simply relied on the fact that people choose a secure (aka hard-to-guess) password. So we just could return to this state. If we choose to do something against password-guessing attacks, we could choose the current solution. This means after n attempts (currently n=17) the account gets locked and only a admin can unlock it. This has the risk that attackers can lock out legitimate users. The trac cookbook list some other possibilities (<URL:https://trac-hacks.org/wiki/CookBook/AccountManagerPluginConfiguration>) to configure the account locking. In general it can be configured to release the lock after some amount of time. However each visit to trac happens at Unix epoch by configuration, so the plugin would never release the lock. If we want to configure automatic unlocking, we would have to change our webserver settings (as far as I see it). How should we set up trac regarding brute-forcing? Are there other possibilities I missed? I'd love to hear your feedback on this. -- Jens Kubieziel http://www.kubieziel.de Wenn der Mensch so viel Vernunft hätte wie Verstand, wäre alles viel einfacher. Dr. Linus Carl Pauling

4 5

Network team meeting, 7 August 2017
by Nick Mathewson 07 Aug '17

07 Aug '17

Hello, friends! We had another network team meeting today. The log is at http://meetbot.debian.net/tor-dev/2017/tor-dev.2017-08-07-17.00.html Notes from the pad are below. A lot of people are out for various time periods during August. Network team meeting, 7 August 2017 Notes from last week: https://lists.torproject.org/pipermail/tor-project/2017-July/001337.html Reminders: - 0.3.1.x was scheduled to be stable last week; nickm postponed it one month to 5 September. - 15 September is the 0.3.2.x freeze. Nick: * Last week - Finished and circulated draft of privcount-in-tor proposal to privcount authors; updated code to match. - Finished reviewing #20657 (prop224, server-side); reviewed first round of fixes. - Reviewed and merged lots of branches, fixed lots of regressions. - Released 0.3.1.5-alpha, 0.3.0.10 - Announced the end of 0.2.4, 0.2.6, and 0.2.7. - Wrote a bunch of little patches * This week - Send privcount draft to tor-dev; open tickets; etc. - Review and comment on tor-client-progress draft. - Review #20657 2nd round of fixes, and maybe 3rd? - Get ready for being out of town next week. Anything I should do/know this week? - More hacking, probably. - Should I do 0.3.1.6-rc this week? (No. Once back from vacation.) komlo: - This week: - first round of rust protover code review by isis - write fuzzing tests for protover ffi - Next week: - Schedule for rust hackfest asn Last week: - Fixing up #20657 branch from nick's review. - Testing #20657 and finding more bugs. - Wrote tons of #20657 unittests. - Did some testing/reviewing on the client-side branch This week: - Get #20657 merged hopefully. - Start reviewing the client-side. pastly: Updating KIST tickets as we speak. David: KIST will be needs_review by the end of the day catalyst: Last week (2017-W31): - helped review #23061 (crypto_rand_double()); floating point is HARD - looked at #22636 log output on failure -- seems OK actually due to the way automake's test rules extract failing/skipped detailed logs into test-suite.log. - dealing with myriad small annoyances of a new house This week (2017-W32): - copy brade's comments about Tor Launcher behavior from #22232 to somewhere more useful like a wiki page - think some more about #23061 - think some more about how Core Tor can help Tor Launcher with bootstrap troubleshooting isis: last week: - began writing up a specification for Ristretto (Decaf point encoding for curve25519), this way we can agree that we're all doing the same encoding, and then I can use it in Hyphae (#22776) - revising patches for the new cmdline key expiration feature (#17639) - some torspec patches https://gitweb.torproject.org/torspec.git/commit/?id=8ebdf2e99f93628055c7d7… https://gitweb.torproject.org/torspec.git/commit/?id=28a8208232cac218b9bbbd… https://gitweb.torproject.org/torspec.git/commit/?id=db17344f15a9e02d041e9d… - laptop had hardware failures and needed to be repaired and then reinstalled :( - also starting building a desktop/build/work machine as well, but that's not finished yet this week: - reviewing Chelsea's Rust protover patch - more work on the moat backend server (#22871) and farfetchd (#15967) - getting ready for my talk at rustconf next week

1 0

July 2017 report for the metrics team
by Karsten Loesing 07 Aug '17

07 Aug '17

Hello Tor, hello world! Below you'll find the highlights of Tor metrics team work done in July 2017. On behalf of the Tor metrics team, Karsten Merged specifications from Metrics sub sites CollecTor [1] and Onionoo [2] into Tor Metrics [3, 4]. [1] https://collector.torproject.org/ [2] https://onionoo.torproject.org/ [3] https://metrics.torproject.org/collector.html [4] https://metrics.torproject.org/onionoo.html Fixed various problems with data on Tor Metrics, including missing server numbers and bandwidth reports [5] and wrongly attributed OnionPerf measurements [6]. [5] https://lists.torproject.org/pipermail/metrics-team/2017-July/000416.html [6] https://lists.torproject.org/pipermail/metrics-team/2017-July/000418.html Released CollecTor 1.2.0 [7] which switches from Torperf to OnionPerf [8] and contains updates to metrics-lib 2.0.0 and to libraries contained in Debian stretch. [7] https://lists.torproject.org/pipermail/tor-dev/2017-July/012372.html [8] https://metrics.torproject.org/stats.html#torperf-1.1

1 0

Damian's Status Report - July 2017
by Damian Johnson 06 Aug '17

06 Aug '17

Yay, pretty things! Couple pictures pretty much sums it up. Here's what I was up to this month... http://blog.atagar.com/july2017/ Cheers! -Damian

1 0

GSoC 2017 Ahmia Status Update #5
by Pushkar Pathak 06 Aug '17

06 Aug '17

Hello everyone, This is the bi-weekly status report for Ahmia - Hidden Service Search ## Added support for subdomains Until now it was not possible for operators to add their sub domains to Ahmia database. Now we have made required modifications in our 'Add' service to support sub domains. [0] ## Documentation I am working on to update all the documentation and software dependencies across Ahmia. [1][2] If time permits, I will try to add advanced search queries using operators like "",|| and &&. Thanks, Pushkar [0]: https://github.com/mdhash/ahmia-site/commits/master [1]: https://ahmia.fi/documentation/ [2]: https://github.com/mdhash/ahmia-site/commit/d3af0b72d9b175c7d3d269119f4dcee…

1 0

SponsorR Status Report July 2017
by George Kadianakis 06 Aug '17

06 Aug '17

Hello, here is the July 2017 report for SponsorR: - Our development team has entered the final stages of coding prop224! We successfuly demoed a proof-of-concept client connection to a prop224 hidden service website on the real network with great results! The remaining prop224 work is testing, bugfixing, stabilization, and improvements. Also, we need to merge all this code upstream in tor-0.3.2 which means a serious review process! - To mark the beginning of this merge procedure, we *merged* upstream the first service-side part of prop224!!! That's a pretty big piece of work: https://trac.torproject.org/projects/tor/ticket/21979 - We also merged upstream some groundwork prop224 tasks: https://trac.torproject.org/projects/tor/ticket/22727 https://trac.torproject.org/projects/tor/ticket/22726 - The final service-side part of prop224 passed its first review rounds, and we have now moved to final review and fixes: https://trac.torproject.org/projects/tor/ticket/20657 https://oniongit.eu/dgoulet/tor/merge_requests/6 - We also finished the client-side branch and we are now starting the review: https://trac.torproject.org/projects/tor/ticket/17242 https://oniongit.eu/asn/tor/merge_requests/2/commits - Fixed an annoying prop224 warning message that was forgotten in 0.3.0: https://lists.torproject.org/pipermail/tor-relays/2017-August/012689.html

1 0

GSoC 2017 - Crash Reporter for Tor Browser: Report #5
by Nur-Magomed 05 Aug '17

05 Aug '17

Hi everyone! This is my bi-week status report for GSoC project "Crash Reporter for Tor Browser". # Crash reporter client: - We considered carefully crash report fields and made decision to reinterpret blacklist feature as allow list [1]; - removed crash event files (some kind of log files that are keeping a few locally crash data even if we sent them - are not the same as crash report files) keeping functional[2] Next steps: # Using new RBM[3] we trying to build Tor browser alpha with crashreporter and make it reproducible # After that we need to test it with server side Kind regards, Nur-Magomed (nmago) [1] https://github.com/nmago/tor-browser/commit/1b3bf799aec4327e99eb0fe0365a637… [2] https://github.com/nmago/tor-browser/commit/0bb8072c03cbf311db2f71d59fdbb6c… [3] https://gitweb.torproject.org/builders/tor-browser-build.git/

1 0

New Website for Nyx (aka arm)
by Damian Johnson 05 Aug '17

05 Aug '17

Hi all, I'm delighted to announce Nyx has a new home! https://nyx.torproject.org/ For those who remember Tor Cloud this is stylistically based on it. Feedback welcome! Tested with Firefox and Chromium. Passes W3C validation and works without JS (though no FAQ). I'll replace arm's old page (https://www.atagar.com/arm/) with a redirect after a while unless folks can think of a reason to keep the old site around. Cheers! -Damian

1 0

GSoC 2017 - unMessage: Report #5
by Felipe Dau 04 Aug '17

04 Aug '17

Hi everyone! This is my report #5 for the unMessage GSoC project. # Updates Since the last report I continued working on #21 [0] and #33 [1]: - Stopped using queues and threads to check for incoming transmissions (that's when the other user starts an action) - Removed disk dependency to run tests without saving any files - Added integration tests to make sure things do not break when making low level changes for the unit tests # What's next Now that I have more confidence to make changes, I am going to start working on the unit tests. I also expect to review with my mentors what has been done for #21 and declare it done. More details on these tasks can be followed in the respective tickets [0, 1], branches [2, 3] and the latest PR [4]. Thanks, -Felipe [0]: https://github.com/AnemoneLabs/unmessage/issues/21 [1]: https://github.com/AnemoneLabs/unmessage/issues/33 [2]: https://github.com/felipedau/unmessage/tree/21/deferreds [3]: https://github.com/felipedau/unmessage/tree/33/feature/test-suite [4]: https://github.com/AnemoneLabs/unmessage/pull/72

1 0

Core Tor team sponsor4 July report
by isabela 04 Aug '17

04 Aug '17

Core Tor Team July 2017 Report In July we reviewed, triaged and fixed misc bugs related to releases 0.3.0 and 0.3.1: * Never send a consensus which the downloader already has. [1] This was an issue we identified that make the most trouble in test networks, where the consensus update rate is so fast that relays frequently try to download a consensus. We investigated and identified what caused the issue and fixed it. * LZMA coder causes crash when the sandbox is enabled. [2] While doing measurements for this project we noticed that Tor instances running as relays or authorities would sometimes crash when the sandbox is enabled. This is due to the MALLOC_MP_LIM value in sandbox.c, which is currently set to 16 MB, being too low. We limit our LZMA coder to only use 16 MB, but the coder allocates some additional data other than its internal buffer, which leads to the crash. * Investigated: Assertion failure in consensus_cache_entry_handle_get on Windows.[3] We created a mitigation and diagnostic branch. It doesn't fix this, but it makes it nonfatal and tries to get more useful info if it happens again. And receive a report that is still present in 0.3.1.4-alpha. Will continue investigation in August. * Bug: src/common/compress.c:576: tor_compress_process: [4] We fixed a bug found 0.3.1 at a stable Gentoo Linux server. * Bridge unavailable during differential consensus update [5] Bug reported for Raspberry Pi running Raspbian. we revised our threadpool implementation to prevent this background work from affecting other background work. There are 3 changelog entries for it in 0.3.1.5-alpha. ** Major bugfixes (relay, performance): Perform circuit handshake operations at a higher priority than we use for consensus diff creation and compression. This should prevent circuits from starving when a relay or bridge receives a new consensus, especially on lower-powered machines. Fixes bug 22883; bugfix on 0.3.1.1-alpha. ** Minor features (directory cache, consensus diff): Add a new MaxConsensusAgeForDiffs option to allow directory cache operators with low-resource environments to adjust the number of consensuses they'll store and generate diffs from. Most cache operators should leave it unchanged. Helps to work around bug 22883. ** Minor features (relay, performance): Always start relays with at least two worker threads, to prevent priority inversion on slow tasks. Part of the fix for bug 22883. Allow background work to be queued with different priorities, so that a big pile of slow low-priority jobs will not starve out higher priority jobs.This lays the groundwork for a fix for bug 22883. * zstd tests fail with libzstd 1.3.0 [6] Write zstd epilogues correctly when the epilogue requires reallocation of the output buffer, even with zstd 1.3.0. (Previously, we worked on 1.2.0 and failed with 1.3.0). * consdiff test fails on OS X [7] test_consdiff_base64cmp would fail on OS X because while OS X follows the standard of (less than zero/zero/greater than zero), it doesn't follow the convention of (-1/0/+1). Make the test comply with the standard. We started to land updates to dir-spec.txt for prop #278 in GL/ahf/torspec/tree/prop278-in-dir-spec [8] And concluded our review of lz4 compressor [9]. For that we added a simple LZ4 test to our own little benchmarking tool [10]. Our results [11] (results) showed that LZ4 is a lot faster than anything else we have (even beats gzip at compression level 1), but the compression ratio is also worse than anything else we have for the cached-consensusdocument (~2.2 MB of structured text). Since we are currently batch processing the compression of our "larger" files in the background we decided we wouldn't win much by including LZ4 here. For August we feel that we are pretty close from finishing this deliverable and we plan to publish a blog post about compression + consensus diff work done with this project. Hope to share that soon. [1] https://trac.torproject.org/projects/tor/ticket/22702 [2] https://trac.torproject.org/projects/tor/ticket/22751 [3] https://trac.torproject.org/projects/tor/ticket/22752 [4] https://trac.torproject.org/projects/tor/ticket/22719 [5] https://trac.torproject.org/projects/tor/ticket/22883 [6] https://trac.torproject.org/projects/tor/ticket/22927 [7] https://trac.torproject.org/projects/tor/ticket/22870 [8] https://trac.torproject.org/projects/tor/ticket/22275 [9] https://trac.torproject.org/projects/tor/ticket/22819 [10] https://gitlab.com/ahf/tor-sponsor4-compression/tree/master/bench [11] https://docs.google.com/spreadsheets/d/1WzFXQGfH8yI4WCCRAEQBt1Z_sC-3hMkmE6H…

1 0