September 2022 - tor-dev - lists.torproject.org

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

Release new version of stem
by Hefee 03 Oct '22

03 Oct '22

Hey, nodens(nodens(a)debian.org) and me are currently packaging the new version of onionshare for Debian and stumbled over the dependency cepa[1], what is a fork of stem. After digging deeper into it, I found out, that the main reason why they do so is the support for Client Auth v3 onions[2]. I really would like not to package a fork of stem, if possible. That's why I ask, when it is planed to release a new version of stem? It hasn't seen any release since 2019 and there are a lot of changes in master branch too. Maybe you can just release the current state of the maint branch, that is actually what is released as cepa 1.8.3. I some how need to solve this till January, when Debian is freezing (not accepting new versions). Regards hefee [1] https://github.com/onionshare/cepa [2] https://github.com/torproject/stem/commit/ 2f3bbf64b4ce3b63160a3c56b15748ba626de4a0

5 8

Blacklist all domains, whitelist .onion,.exit
by nyxnor 21 Sep '22

21 Sep '22

Hello. I am trying to make a tor only allow traffic through onion services and exit nodes. I would like to blacklist all domains first, as that is simple and does not need to be updated, then whitelist all onions and exits. Reason: I am hosting an onion service, but I don't want any client traffic comming from that machine. I've played with MapAddress, VirtualAddrNetworkIPV4, AutomapHostsOnResolve, AutomaptHostsSuffixes, but nothing seems to work as intended above. MapAddress *=127.0.0.1 does not report invalid conf, but the controller reports it is using invalid sytax because "*" be source or target. I tricked the controller with MapAddress *.*=127.0.0.1, as every domain has a dot, the controller didn't report syntax error and this option is actually ignored. If the above worked, then the next option would be the whitelisting: MapAddress *.onion VIRTUAL_IP Or possibly the AutomapHostsOnResolve 1 and AutomapHostsSuffixes .exit,.onion would handle that part hopefully. I did the lazy way, the antivirus way, I downloaded the IANA TLD domain list and used basic string manipulation to make: MapAddress *.${domain} 127.0.0.1 And yes, as you may think, the list is huge that has to be on its own included conf file, and also prone to be outdated every time a new TLD is created. But it works, in a dumb and prone to mistakes, it works. Can this be done better? Not antivirus way of all is permitted, some known items are blocked. I would prefer all is blocked and some items are permitted. The real objective was to block all non .onion and .exit targets coming from a client, that the controller reports with SOURCE_ADDR, but I didn't find an option to MapAddress per client or anything similar to that do manipulate addresses per client source, so that is why I started doing this for all tor traffic, which is not what I really want, but controlling targets per client.

1 0

GSoC 2022 - Tor Weather: Improving the Tor Network
by Sarthik Gupta 19 Sep '22

19 Sep '22

Hello everyone, I’m Sarthik Gupta (irc: sarthikg), a recent grad from Punjab Engineering College, Chandigarh & currently working as a Software Engineer at Soroco. This summer, I’ll be working on GSoC Project: “Tor Weather: Improving the Tor Network” with my mentors GeKo & Silvia. I’m extremely excited to be a part of Tor and am interested in working on this project! Briefing about the project: As of now, if any relay disappears from the tor-network, no one will know. This causes the network to lose out on bandwidth from nodes which have been down for hours because no-one knew they were down. Tor-Weather aims at solving this by creating a notification service which relay operators can subscribe to in order to get various types of updates for their relays. The tor-weather service will offer a plethora of notifications options for the relays. These include, the node being down, running on EOL/Outdated version, losing a flag, ranking in top 20/50/100, etc. These notifications can be subscribed & customised by the relay operators to fit their needs using a web-frontend. A detailed proposal for this project is available at: <https://gitlab.torproject.org/sarthikg/tor-weather/-/wikis/Proposal> https://gitlab.torproject.org/sarthikg/tor-weather/-/wikis/Proposal. I plan to keep this wiki updated with the progress & design decisions taken throughout the development of the project. Suggestions are always welcomed! Please reach out to us in irc (#tor-dev) for any ideas, questions, or suggestions you might have. Thanks, Sarthik Gupta

1 5

Shortcuts to data-heavy parts of the bootstrapping process
by Holmes Wilson 07 Sep '22

07 Sep '22

I was just at an event with a slow (but reliable) network and Tor was not able to connect; the "Loading relay descriptors" step just took too long. At some point I got an error message that indicated that it was giving up but that I had enough information to connect to onion addresses. I can't reproduce the problem now on a normal network, and I just went through the Tor code looking for the error message I saw, but I couldn't find it. But I figured I'd ask here to see if anyone was familiar with shortcuts Tor can take in its connection process that safely save time and bandwidth on slow connections if the only thing I intend to use Tor for is connecting to onion addresses. Are there any steps in bootstrapping that can be skipped if I only care about making and receiving onion address connections? Holmes

2 2