- tor-dev - lists.torproject.org

Adding Tracing to little-t tor
by David Goulet 17 Jan '20

17 Jan '20

Greetings tor-dev! This email is a discussion on adding tracing to little-t tor. Tracing can be a very abstract notion sometimes so I'll start with a quick overview of what that is, what we can achieve and use cases within tor. Then I'll go over a last point which is safety. This email doesn't go into the technical details of userspace tracing on how and what will be done to add it to tor. That is for another discussion. 1. Overview Long story short, you can see tracing as a specific type of logging as in it records information of the application at runtime using tracepoints (similar to logging statement) so it can be used later. But the main differences from logging are in two parts: performance and API stability. Usually, tracing implies high performance as in adds very little overhead to the application in order to disrupt as little as possible the normal behavior of an application. This is extremely useful in cases where you want to catch race conditions or performance bottle necks. Tracers in userspace have usually an "inprocess library" which in short means that it records data (raw) from the application and move it to an outside buffer. Then, that buffer is emptied either on disk or network by the outside component of the tracer for which the data can be analyzed after collection. So all a tracer do is, within the application when a tracepoint is hit, copy some data into a buffer and yields back to the application. The other part is the API stability. Very often, logs (let say at DEBUG level) don't usually have strict stable requirements between released versions. But tracing events (tracepoints), are exposed to the outside for tracers to hook on, and for people to run analyzing tools on the recorded data. Thus, stability is usually strongly encouraged. In other words, what the tracepoint exposes, once released stable, should really not change that much over time. With a proper abstraction in the application, we can offer stable tracepoints for which a variety of tracers can hook themselves on at runtime. It is all about providing an interface to the outside world. 2. Why Tracing in Tor The tor software is a very complex beast. It has dozens of subsystems with various interactions between them. One of the big main job of tor is to relay data as fast as possible in order to keep the latency low. Which means, that there are code paths that are considered "fast path" implying that they must remain light and fast. One example is the crypto code that is hit at each cell. Tracing comes in extremely handy to hunt down race conditions, performance issues, or even multithreading problems. A fast relay, let say 25MB/s, if we wanted to record cell timing in order to hunt down such issues, it simply can _not_ be done with logging at debug level since it slows down considerably tor but also fills the disk in a matter of minutes. And using the control port is not a good solution for two main reasons: string formatting at each event and control port is part of the mainloop. So anything you ask to go on the control port will add an overhead to the overall behavior of tor which is not good when you hunt down races. One concrete example where tracing was used in the past in tor is with the rewrite of the cell scheduler (KIST). In order to measure cell timings within Tor so bottlenecks issues could be found, tracing had to be added so millions of events could be recorded within few minutes of using a fast relay in production. In pressure situation, this is where tracing comes handy. Tracing was also used recently to find onion service v3 reachability issues. In order to correlate connection, cell and circuit level problems with the higher level HS subsystem, we were able to record events in all those subsystems, match them with their precise timing (offered by tracing) and analyze the results later on after recording the data. 3. Safety Discussion Onto the last part I wanted to raise. Allowing anyone to record very low level data from tor, there is an obvious safety question that must be raised. Over the years, I've talked about tracing with many people in Tor and the consensus was always that it should never be enabled in production. As in, the packages shipped by Tor or by distros should _never_ build the tracepoints. In other words, it should be considered a development option only. Not only an option, but compiled _out_ in production and one has to explicitly build them into tor. For example (nothing final, just to show the idea): $ ./configure --enable-tracing I personally think that should be enough since the presence of the code upstream won't stop people from using it (bad or not) but we can prevent it to be in any legit Tor packages out there. See it a bit like the obsolete Tor2web option that was never enabled in any published packages by Tor Project or distros, one had to explicitly enable it at configure time. The ControlPort is allowed in production and if a malicious actor gets access to it, then game over. I do see tracing like that as well but at least we can control its availability as a feature where we can't for the ControlPort as of today. Any feedback is very welcome! Concerns, questions, thoughts. Cheers! David -- AOrq46damX3clZogjR9FlXTru90GV9IT5Rq/J0EzVSA=

3 4

OK got mix vanguards from packages.debian.org with Tor from deb.torproject.org repository?
by Patrick Schleizer 17 Jan '20

17 Jan '20

I am considering to install vanguards by default in Whonix. Is it sane to mix the Debian 'tor' package deb.torproject.org (buster repository) with packages.debian.org buster version of 'vanguards' or do you foresee any issues? Cheers, Patrick

2 2

Snowflake server and traffic analysis questions
by procmem＠riseup.net 15 Jan '20

15 Jan '20

Goal: We (Whonix) are researching optional bridge hosting for our users to thwart web fingerprinting. Snowflake makes the most sense since no NAT hole-punching is needed. Correct me if I'm wrong here because if that was possible with obfs4 or meek it would save a lot of work. We now know acting as a bridge makes the user act as a guard node and not just a rendezvous to one.[1] [1] https://tor.stackexchange.com/questions/3636/what-is-the-relationship-betwe… Some questions to help with implementation: * Do the user's own data go through just two hops as well or are they sent to the guard node they chose before deciding to run as a bridge? How do configure Tor to do the former if it isn't? * Are there plans to create signed debs for snowflake client/server so we can use it with Debian's tor daemon? * Do Tor Browser bundles with the snowflake addon also include the server component? * Do Alpha bundles have this code yet? * When are these bundles expected to arrive to stable? * Is it possible to interact headlessly with the snowflake server component via commandline? How? * How can we run TBB headlessly so users don't mistakenly interact with it on the gateway?

2 1

Updates to Prop306: A Tor Implementation of IPv6 Happy Eyeballs
by Neel Chauhan 15 Jan '20

15 Jan '20

Hi tor-dev@ mailing list, Sorry for the many-months delay in updating Prop306. I have updated Prop306, which is the IPv6 Happy Eyeballs proposal. The GitHub PR is here: https://github.com/torproject/torspec/pull/98 The Trac ticket is here: https://trac.torproject.org/projects/tor/ticket/29801 Some of the older discussion on Prop306 can be seen on the thread here: https://lists.torproject.org/pipermail/tor-dev/2019-August/013959.html Could some of you please review this proposal? -Neel === https://www.neelc.org/

2 3

Tor Proposal 295
by Tomer Ashur 14 Jan '20

14 Jan '20

Dear all, Please find attached out final version for Proposal 295. This version has two changes compared to the previous one: 1. It fixes a vulnerability introduced in the previous iteration which was the result of making the authentication layer stateless. Since there is no freshness entering into the first layer, the same plaintext would have resulted in the same ciphertext thus allowing an adversary to distinguish. This is now fixed by restoring the running digest also for authentication layer thus making in stateful again. 2. It adds an option for forward secrecy. The approach here is similar to the one taken by Proposal 308 by replacing the encryption key of the first layer after successfully processing the message. If this approach is taken, there is no need to keep the authentication layer stateful anymore. I'll be leaving the mailing list to reduce noise in my mailbox. If you need anything from me regarding this proposal just make sure to CC me on the email and I'll be happy to answer. Wishes, Tomer

1 0

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