December 2019 - tor-dev - lists.torproject.org

Onion DoS: Killing rendezvous circuits over the application layer
by George Kadianakis 10 Dec '19

10 Dec '19

Greetings! This is another thread [0] about onion service denial-of-service attacks. It has long been suggested that onion service operators should be given the option to kill spammy rendezvous circuits at will if they feel they are causing too much damage. Right now this is possible using the HiddenServiceExportCircuitID torrc option (introduced in #4700) and then using the CLOSECIRCUIT control port command to close circuits. Unfortunately, we have recently got reports that this technique is not viable for busy onion services under DoS because their control port gets overwhelmed by (useful for them) events, and it's basically rendered useless to the point that any CLOSECIRCUIT command takes several seconds to become effective. For this reason, multiple onion operators [1] have resorted to using the actual HTTP protocol as a direct channel of communication to the Tor daemon to request circuit shutdowns. This works by embedding a special string (or HTTP error code) to the HTTP responses from nginx to the Tor daemon and adding special custom code to the Tor daemon to close circuits that carry this string. This seems to work well enough for people so far. This is a thread to discuss this approach and other alternatives since it seems a useful tool against application-layer onion service denial of service attacks. Let me go through the positives and negatives of actuallym erging this defence upstream to little-t-tor: --- Positives: 1) This is a solid defense that actually helps people and has been reported as a positive countermeasure in an area that has been hard to find concrete defences (also see [0]). 2) Seems like more and more people are doing this already in a custom ad-hoc fashion, so merging this upstream will at least give them a secure way of doing it (instead of writing custom C code). 3) It's actually a pretty simple patch in terms of tech-debt and maintaining it. 4) The more we address DoS vectors like this one, the less incentive will exist for DoS actors to exist. Effectively improving the long-term health of the network. Negatives: a) It's a dirty hotfix that blends the networking layers and might be annoying to maintain in the long-term. b) It only works for HTTP (and without SSL?). --- For me, point (1) is extremely important, since we've been struggling with helping onion services that are getting DoSsed and this feature offers a solid defense against practical attacks. However, IMO the right way to do this feature, would be to improve the control port code and design so that it doesn't get so overwhelmed by multiple events. That said, I'm not sure exactly what kind of changes we would have to do to the control port to actually make it a viable option, and it seems to me like a pretty big project that serves as a medium-term to long-term solution (which we have no resources to pursue right now), whereas the hack of this thread is more of a short-term solution. I'm looking forward to constructive feedback here, since this seems like a controversial feature that users really need. Thanks! :) [0]: serving as a continuation of previous classics such as: https://lists.torproject.org/pipermail/tor-dev/2019-June/013875.html https://lists.torproject.org/pipermail/tor-dev/2019-July/013923.html etc. [1]: http://www.hackerfactor.com/blog/index.php?/archives/804-A-New-Tor-Attack.h… https://trac.torproject.org/projects/tor/ticket/32511

4 3

Trip Report: Reproducible Builds Summit
by Hans-Christoph Steiner 09 Dec '19

09 Dec '19

I was at the 5th Reproducible Builds Summit this past week, representing mostly Android topics. I attended the first two, so it was nice to see that there has been some real progress in the past few years of work. My main focus was working with an Apache/Maven developer on implementing the "buildinfo" spec for publishing reproducible Java JAR builds to Maven Central and other Maven repositories. Maven repositories are central to the whole Android and Java ecosystems as the primary means of getting libraries. We used the jtorctl library to prototype how this system will look when using the Maven, Gradle, and Bazel buildsystems. Given the results of our brief work, we should have something working and deployed this year. And there is already a Maven plugin for publishing the "buildinfo" files. So it should be easy to start getting libraries to publish these to Maven Central and other Maven repositories. Then the Apache/Maven Developer plans to push Apache Software Foundation to require reproducible builds for all its official Java releases. If you want to help with this effort, you can start publishing buildinfo files with your library, or try rebuilding libraries based on published buildinfo files to test whether there is enough information to reproduce the builds. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

1 0

Open Source Design Workshop, Brussels, January 31
by sajolida 04 Dec '19

04 Dec '19

The fine folks at Open Source Design are organizing on January 31 a practical workshop on usability testing: https://hsbxl.be/events/byteweek/2020/opensourcedesign/ It will happen in Brussels, 1 day before FOSDEM. >From the author and the description of the workshop I expect it to imply invaluable knowledge for free. Everybody interested in developing or designing usable software but without academic training on usability testing should attend a workshop like this. I'm not sending this email to UX mailing lists on purpose :) -- sajolida Tails — https://tails.boum.org/ UX · Fundraising · Technical

1 0

HSv3 descriptor work in stem
by George Kadianakis 04 Dec '19

04 Dec '19

Hello atagar, I'm starting this thread to ask you questions about stem and the HSv3 work we've been doing over email so that we don't do it over IRC. Here is an initial question: I'm working on HSv3 descriptor encoding, and I'm trying to understand how `_descriptor_content()` works. In particular, I want to compute the signature of a descriptor, but I see that `descriptor_content()` fills it with random bytes in all the `content()` methods I managed to find: ('signature', _random_crypto_blob('SIGNATURE')), What's the right way to compute the signature for such objects? In particular, I would need a method that first generates the whole descriptor body, and then computes the signature of that with a given private key. Can I use `_descriptor_content()` to do that? Or should I call `_descriptor_content()` to generate the whole thing _without_ the sig, and then do the signature computation on its result and concatenate it after? Thanks! :)

3 10