tor-dev April 2022

tor-dev@lists.torproject.org

5 participants
5 discussions

Two features that would help load-balanced bridges
by David Fifield 01 Jun '23

01 Jun '23

After the blocking of Tor in Russia in December 2022, the number of Snowflake users rapidly increased. Eventually the tor process became the limiting factor for performance, using all of one CPU core. In a thread on tor-relays, we worked out a design where we run multiple instances of tor on the same host, all with the same identity keys, in order to effectively use all the server's CPU resources. It's running on the live bridge now, and as a result the bridge's bandwidth use has roughly doubled. Design thread https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-s… Installation instructions https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Gui… Two details came up that are awkward to deal with. We have workaround for them, but they could benefit from support from core tor. They are: 1. Provide a way to disable onion key rotation, or configure a custom onion key. 2. Provide a way to set a specific authentication cookie for ExtORPort SAFE_COOKIE authentication, or a new authentication type that doesn't require credentials that change whenever tor is restarted. I should mention that, apart from the load-balancing design we settled on, we have brainstormed some other options for scaling the Snowflake bridge or bridges. At this point, none of these ideas can immediately be put into practice, because there's no way to tell tor "connect to one of these bridges at random, but only one," or "connect to this bridge, but accept any of these fingerprints." https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… # Disable onion key rotation Multiple tor instances with the same identity keys will work fine for the first 5 weeks (onion-key-rotation-days + onion-key-grace-period-days), but after that time the instances will have independently rotated their onion keys, and clients will have connection failures unless the load balancer happens to connect them to the instance whose descriptor they have cached. This post investigates what the failure looks like: https://lists.torproject.org/pipermail/tor-relays/2022-January/020238.html Examples of what could work here are a torrc option to set onion-key-rotation-days to a large value, an option to disable onion key rotation, an option to set a certain named file as the onion key. What we are doing now is a bit of a nasty hack: we create a directory named secret_onion_key.old, so that a failed replace_file causes an early exit from rotate_onion_key. https://gitweb.torproject.org/tor.git/tree/src/feature/relay/router.c?h=tor… There are a few apparently benign side effects, like tor trying to rebuild its descriptor every hour, but it's effective at stopping onion key rotation. https://lists.torproject.org/pipermail/tor-relays/2022-January/020277.html # Stable ExtORPort authentication ExtORPort (extended ORPort) is a protocol that lets a pluggable transport attach transport and client IP metadata to a connection, for metrics purposes. In order to connect to the ExtORPort, the pluggable transport needs to authenticate using a scheme like ControlPort authentication. https://gitweb.torproject.org/torspec.git/tree/proposals/217-ext-orport-aut… tor generates a secret auth cookie and stores it in a file. When the pluggable transport process is managed by tor, tor tells the pluggable transport where to find the file by setting the TOR_PT_AUTH_COOKIE_FILE environment variable. In the load-balanced configuration, the pluggable transport server (snowflake-server) is not run and managed by tor. It is an independent daemon, so it doesn't have access to TOR_PT_AUTH_COOKIE_FILE (which anyway would be a different path for every tor instance). The bigger problem is that tor regenerates the auth cookie and rewrites the file on every restart. All the tor instances have different cookies, and snowflake-server does not know which it will get through the load balancer, so it doesn't know what cookie to use. Examples of what would work here are an option to use a certain file as the auth cookie, an option to leave the auth cookie file alone if it already exists, or a new ExtORPort authentication type that can use the same credentials across multiple instances. What we're doing now is using a shim program, extor-static-cookie, which presents an ExtORPort interface with a static auth cookie for snowflake-server to authenticate with, then re-authenticates to the ExtORPort of its respective instance of tor, using that instance's auth cookie. https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html

2 2

Metrics: Estimating fraction of reported directory-request statistics
by David Fifield 27 Jun '22

27 Jun '22

I am trying to reproduce the "frac" computation from the Reproducible Metrics instructions: https://metrics.torproject.org/reproducible-metrics.html#relay-users Which is also Section 3 in the tech report on counting bridge users: https://research.torproject.org/techreports/counting-daily-bridge-users-201… h(R^H) * n(H) + h(H) * n(R\H) frac = ----------------------------- h(H) * n(N) My minor goal is to reproduce the "frac" column from the Metrics web site (which I assume is the same as the frac above, expressed as a percentage): https://metrics.torproject.org/userstats-relay-country.csv?start=2022-04-01… date,country,users,lower,upper,frac 2022-04-01,,2262557,,,92 2022-04-02,,2181639,,,92 2022-04-03,,2179544,,,93 2022-04-04,,2350360,,,93 2022-04-05,,2388772,,,93 2022-04-06,,2356170,,,93 2022-04-07,,2323184,,,93 2022-04-08,,2310170,,,91 I'm having trouble with the computation of n(R\H) and h(R∧H). I understand that R is the subset of relays that report directory request counts (i.e. that have dirreq-stats-end in their extra-info descriptors) and H is the subset of relays that report directory request byte counts (i.e. that have dirreq-write-history in their extra-info descriptors). R and H partially overlap: there are relays that are in R but not H, others that are in H but not R, and others that are in both. The computations depend on some values that are directly from descriptors: n(R) = sum of hours, for relays with directory request counts n(H) = sum of hours, for relays with directory write histories h(H) = sum of written bytes, for relays with directory write histories > Compute n(R\H) as the number of hours for which responses have been > reported but no written directory bytes. This fraction is determined > by summing up all interval lengths and then subtracting the written > directory bytes interval length from the directory response interval > length. Negative results are discarded. I interpret this to mean: add up all the dirrect-stats-end intervals (this is n(R)), add up all the dirreq-write-history intervals (this is n(H)), and compute n(R\H) as n(R) − n(H). This seems wrong: it would only be true when H is a subset of R. > Compute h(R∧H) as the number of written directory bytes for the > fraction of time when a server was reporting both written directory > bytes and directory responses. As above, this fraction is determined > by first summing up all interval lengths and then computing the > minimum of both sums divided by the sum of reported written directory > bytes. This seems to be saying to compute h(R∧H) (a count of bytes) as min(n(R), n(H)) / h(H). This is dimensionally wrong: the units are hours / bytes. What would be more natural to me is min(n(R), n(H)) / max(n(R), n(H)) × h(H); i.e., divide the smaller of n(R) and n(R) by the larger, then multiply this ratio by the observable byte count. But this, too, only works when H is a subset of R. Where is this computation done in the metrics code? I would like to refer to it, but I could not find it. Using the formulas and assumptions above, here's my attempt at computing recent "frac" values: date `n(N)` `n(H)` `h(H)` `n(R)` `n(R\H)` `h(R∧H)` frac 2022-04-01 166584 177638. 2.24e13 125491. 0 1.59e13 0.753 2022-04-02 166951 177466. 2.18e13 125686. 0 1.54e13 0.753 2022-04-03 167100 177718. 2.27e13 127008. 0 1.62e13 0.760 2022-04-04 166970 177559. 2.43e13 126412. 0 1.73e13 0.757 2022-04-05 166729 177585. 2.44e13 125389. 0 1.72e13 0.752 2022-04-06 166832 177470. 2.39e13 127077. 0 1.71e13 0.762 2022-04-07 166532 177210. 2.48e13 127815. 0 1.79e13 0.768 2022-04-08 167695 176879. 2.52e13 127697. 0 1.82e13 0.761 The "frac" column does not match the CSV. Also notice that n(N) < n(H), which should be impossible because H is supposed to be a subset of N (N is the set of all relays). But this is what I get when I estimate n(N) from a network-status-consensus-3 and n(H) from extra-info documents. Also notice that n(R) < n(H), which means that H cannot be a subset of R, contrary to the observations above.

2 4

Discussion about Tor Directory Authority Consensus Code
by Zhongtang Luo 26 Apr '22

26 Apr '22

Hi all! I am a PhD student currently doing some experiments on Tor. My advisor and I was wondering if we can talk to somebody who takes care of the Tor Directory Authority code, since there is a conceptual issue we wish to communicate with them. Can somebody direct us to the appropriate person? Many thanks. Yours, Zhongtang Luo

2 1

We built a new Tor-based team chat prototype. Wanna try it?
by Holmes Wilson 15 Apr '22

15 Apr '22

Hi everyone, My collaborators and I have been working for the past couple years on building a Tor-based team chat app which we're calling Quiet*, and I'm curious if anyone here would like to try it out! If you would, please reply! :) I am especially interested in feedback from Tor project participants and people who are sometimes in the position of advising organizations on their security needs, but everyone on this list is welcome! What I'll try to do is find a time that would work for all of us so we can try it together in a true test of its team chat possibilities, though if that doesn't work I'm happy to do one on one meetings too. Quiet is still lacking pretty much every feature imaginable except adding team members and sending and receiving messages. And mobile apps aren't ready yet. And it hasn't been audited so it shouldn't be used for anything important at all. And so on. But if you've tried any attempts at p2p group chat before, this one will strike you as surprisingly reliable thanks in no small part to the reliability of Tor. So it's pretty cool to see it in action and it's a fun new way to use Tor. Again, I'm not looking for any real end users at this stage—we're just not ready for that yet. But we've invested a lot in usability and reliability and we're making a really serious go of it. This isn't vaporware and I think it'll be worth your time to check it out! :) Perhaps the coolest part about our approach is that its usefulness goes way beyond chat apps. The approach we've taken is adequate for building private, F/OSS alternatives to a large class of crucial applications that currently lack strong privacy and security properties, such as Trello, Asana, Basecamp, Google Docs and Sheets, Figma, Discourse, Airtable, team password managers, and more. Specifically, you can use it to build any application where a bounded group of people share some common workspace, as long as the data would fit on a typical consumer device. And perhaps from that foothold we can figure out ways to extend the model to be adequate for building large unbounded networks like Signal, Twitter, and Facebook in a decentralized way, though that's a much harder class of problem. (I gave this talk <https://archive.org/details/hopeconf2020/20200802_1600_Zbay%2C_Fighting_FAA…> a couple years back at HOPE 2020 about these ideas which is a pretty good overview of the motivations behind the project, and and I'll be speaking again at HOPE 2022 this summer about where we're at now, so it would be great to meet up there if anyone else will be there!) I've included some more notes below on how it works for those who are curious. But if you're curious please write me back so I can give you a demo :) Holmes # How it works Quiet is like a combination of Slack and Ricochet. Ricochet did not depend on any servers except for the Tor network itself, and sent messages directly over onion services, but it was only for 1:1 messaging. Like Ricochet, Quiet doesn't require any servers except for the Tor network itself, but it uses some p2p libraries that have emerged over the past few years to enable group chat where—like Slack and Discord—all clients tend to display the same message history, even clients that were offline when messages were sent. Specifically, Quiet uses OrbitDB, a CRDT. CRDTs are sort of like Git, where they enable syncing between decentralized peers such that all peers eventually converge on the same state. OrbitDB is built on IPFS, so unlike a lot of CRDTs (like Automerge) it comes with some built-in ability to move data around between peers. IPFS is pretty flexible and we set it up so that each team has its own totally isolated IPFS network, and all the IPFS clients connect to each other over Tor. There's no big, global, leaky p2p network, and no blockchain or anything like that. You have a group of friends, and you just talk to each others onions. That's it. To invite a new user, an authorized user shares an onion service link to a "registrar" onion service running on their machine, and they add that new user's key information to a user table, and give the user a certificate they can use to connect to other peers. A single community owner uses certificates to grant unique usernames. Mobile apps use the same approach, though we'll need a centralized service for notifications on iOS until someone changes the way Apple Apples, and we haven't built that yet. There are a lot of other important pieces of the design we haven't tackled yet too, such as timed message deletion, removing users, use of onion auth for incoming connections, optimizations for very large communities, and so on. But it's all fairly tractable, if a bit slow going. (I'm also really interested if this description is clear and would love your feedback and questions!)

1 0

Interoperation with libp2p
by Mike Mestnik 07 Apr '22

07 Apr '22

https://gitlab.torproject.org/tpo/core/torspec/-/issues/64

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev April 2022