- tor-dev - lists.torproject.org

Changes to accessing and using MaxMind's databases
by Karsten Loesing 13 Jan '20

13 Jan '20

Hi! When trying to update tor's geoip databases the other day I found that MaxMind's GeoLite2 database is not available for download anymore. The reason is: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-us… We do not have a MaxMind account (yet). As of now, we cannot update tor's geoip files nor the files used by Onionoo. Should we try to get somebody who knows more about licenses and legal stuff to review their GeoLite2 EULA and tell us if it's okay for us to sign up for a MaxMind account? A possible downside would be that whoever wants to verify that we didn't mess with their database when converting it to our format would have to sign up for an account, too. An alternative is to find another, truly open data source than MaxMind databases (#25542, #26585). However, this could eat up more time than we currently have available, and we should have something ready in a few weeks from now. I'm not sure how we would squeeze this into the metrics team schedule, so we might need help with this. Thoughts on the two alternatives? What else did I miss? All the best, Karsten

2 1

Should we remove the ClientAutoIPv6ORPort option?
by Neel Chauhan 12 Jan '20

12 Jan '20

Hi tor-dev@, Ticket: https://trac.torproject.org/projects/tor/ticket/32905 GitHub PR: https://github.com/torproject/tor/pull/1652 Considering that people had issues with the ClientAutoIPv6ORPort option, like when IPv6 was tried on IPv4-only connections in [1] and [2], I think we should just remove the ClientAutoIPv6ORPort option. Plus, we are going to do real Happy Eyeballs in Prop306, making ClientAutoIPv6ORPort redundant. Should we? -Neel Sources: [1] - https://blog.torproject.org/comment/281976#comment-281976 [2] - https://blog.torproject.org/comment/282102#comment-282102

1 0

Request info about how the Tor HS DoS works
by juanjo 07 Jan '20

07 Jan '20

Hello, since months ago we are debating proposals about how to stop HS being DDoSed. We have many open issues and even developed in a rush a fix "just for the network" (not HS availability). But, I have not seen yet a good explanation about what is really happening when HS is being DDoSed by this famous and effective attack. I mean, the only thing I know about it is that its goal is to send a ton of INTRODUCE2 cells to the HS, but, what is the cost for the attacker? Some questions need to be answered, at least If I want to understand it and make a proposal for fixing this issues. *Questions:* Is the attacker building a circuit to the Rendz point as expected by the protocol? How can we be sure of that? -Attacker (client) to Rendezvous point circuit: What is exactly happening on this circuit and how can the attacker improve the attack? Is the attacker using the same Rendz over and over for its INTRODUCE1? A new circuit to the Rendz? Can the first two hops of a circuit be reused (only changing the exit node) so it can build a new circuit to a new Rendz faster and make the attack better? -Attacker (client) to Intro point: what is exactly happening on this side of the equation? Sorry, but I could not find the answer to these questions and what is going on on any ticket or this mail lists.

1 0

Bridge benefits stackable?
by procmem＠riseup.net 02 Jan '20

02 Jan '20

Hi. We are considering allowing users to run their daemon (optionally) as a bridge in addition to client mode for increased traffic fingerprinting resistance [1]. Does running a bridge prevent you from using a bridge yourself? I've seen it mentioned that using bridges can protect users in event of a malicious guard node. Can the benefits of being a bridge and connecting to one be stacked? What is the best practice here? Happy New Year. [1] https://blog.torproject.org/new-low-cost-traffic-analysis-attacks-mitigatio…

1 0

Stem and Nyx bug tracking moved
by Damian Johnson 22 Dec '19

22 Dec '19

Hi all. Stem and Nyx's issue tracking has moved from Trac to GitHub. In the future please file tickets at... https://github.com/torproject/stem/issues/ https://github.com/torproject/nyx/issues/ Thanks! PS. All existing tickets have moved. These trac components will be disabled to cut down on confusion... https://trac.torproject.org/projects/tor/ticket/32832

1 0

(No Subject)
by techniquea2z＠protonmail.com 14 Dec '19

14 Dec '19

I am working on nibirumrx3wruiqf and have some questions: How to setup DDOS protection on the VPS & nginx levels? Any guidelines on nginx configurations for scale? How does mirroring work? I imagine you'd open many ports on the torrc, and have nginx listen to different instances of the same app on different http ports. If this project interests you and you want to collaborate, contact me

1 0

Probability of Guessing a v3 Onion Address
by procmem＠riseup.net 12 Dec '19

12 Dec '19

Hi I was wondering what the mathematical probability of guessing an onion v3 address that is kept secret. Or asked differently: what is the entropy of v3 addresses if an adversary decides to bruteforce the entire keyspace? I am struggling to come up with a usecase for authenticated v3 services when keeping an address secret has the same effect and one can generate multiple addresses for the same server and share them with different entities. The degraded usability of v3 auth services compared to v2 is the reason I'm asking.

3 2

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