February 2022 - tor-relays - lists.torproject.org

How to reduce tor CPU load on a single bridge?
by David Fifield 18 Dec '22

18 Dec '22

The main Snowflake bridge (https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6…) is starting to become overloaded, because of a recent substantial increase in users. I think the host has sufficient CPU and memory headroom, and pluggable transport process (that receies WebSocket connections and forwards them to tor) is scaling across multiple cores. But the tor process is constantly using 100% of one CPU core, and I suspect that the tor process has become a bottleneck. Here are issues about a recent CPU upgrade on the bridge, and observations about the proportion of CPU used by different processes: https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… I have the impression that tor cannot use more than one CPU core—is that correct? If so, what can be done to permit a bridge to scale beyond 1×100% CPU? We can fairly easily scale the Snowflake-specific components around the tor process, but ultimately, a tor client process expects to connect to a bridge having a certain fingerprint, and that is the part I don't know how to easily scale. * Surely it's not possible to run multiple instances of tor with the same fingerprint? Or is it? Does the answer change if all instances are on the same IP address? If the OR ports are never used? * OnionBalance does not help with this, correct? * Are there configuration options we could set to increase parallelism? * Is migrating to a host with better single-core performance the only immediate option for scaling the tor process? Separate from the topic of scaling a single bridge, here is a past issue with thoughts on scaling beyond one bridge. it looks as though there are not ways to do it that do not require changes to the way tor handles its Bridge lines. https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… * Using multiple snowflake Bridge lines does not work well, despite that we could arrange to have the Snowflake proxy connect the user to the expected bridge, because tor will try to connect to all of them, not choose one at random. * Removing the fingerprint from the snowflake Bridge line in Tor Browser would permit the Snowflake proxies to round-robin clients over several bridges, but then the first hop would be unauthenticated (at the Tor layer). It would be nice if it were possible to specify a small set of permitted bridge fingerprints.

7 57

relayor v22.0.0-rc is released
by nusenu 03 Dec '22

03 Dec '22

Hi, relayor v22.0.0-rc is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes since relayor v21.2.0-rc: * MetricsPort support improvements: * generate nginx reverse server config for remote prometheus scraping on the relay (we do not install nginx) * generate htpasswd file for HTTP basic auth of MetricsPort on the relay * debian/ubuntu: support new alpha repos (branch name is no longer included in the repo name). * FreeBSD 12.3 is supported kind regards, nusenu -- https://nusenu.github.io

2 4

Loss of Guard and HS Dir flags
by Eddie 29 May '22

29 May '22

I currently run 3 relays, across different servers and today I noticed that one has now lost it's Guard and HS Dir flags. What's surprising is that this particular relay has the highest Bandwidth and Consensus Weight of all 3 and has not been restarted for over a month. The stats for all 3 can be found with: OhNoAnotherRelay I know that just running the relay is the important part and caring about what flags it has is a side issue, but I'm just interested in seeing why this has happened. Cheers.

4 7

Tor 0.3.5.x is unsupported, please upgrade
by Georg Koppen 21 Mar '22

21 Mar '22

Hello! It's time again to get relays upgraded running an EOL Tor series (0.3.5.x). We'll start reaching out to operators with valid contact information this week and plan to start reject relays which are still on 0.3.5.x about 4 weeks from now on at the begin of March. You can follow along that process in our bug tracker[1] if you want. For the general processes around dealing with EOL relays in the Tor network see my mail from last October[2]. Feedback and improvements are welcome, as always. Georg [1] https://gitlab.torproject.org/tpo/network-health/team/-/issues/171 [2] https://lists.torproject.org/pipermail/tor-relays/2021-October/019862.html

1 1

Ansible role to deploy Bridges
by Erasme - Relay Operator 09 Mar '22

09 Mar '22

Hi all, In the effort of deploying obfs4 bridges for the community we are sharing our Ansible role that allowed us to deploy multiple nodes: https://github.com/NewNewYorkBridges/ansible-tor-bridge For now it is only available on Debian but we will make it available for other distributions. We hope this role is helpful for the community. Feel free to send us your feedback! Kind regards, Erasme

3 2

Tor Relay Meetup #Fosdem Notes
by gus 04 Mar '22

04 Mar '22

Hello, Last Saturday, a group of 30 - 40 operators joined the Tor Relay Operator meetup. Thank you all for joining the event! Our next online meetup will happen on March 5th, 2000 UTC. Gus ## Fosdem Meetup Notes * Bridges campaign update: "When we started the campaign on November 17, 2021, the Tor network had approximately 1,200 running bridges. The Tor network now has 2470 running bridges, i.e., the number of Tor bridges has almost doubled!" https://blog.torproject.org/wrapping-up-bridges-campaign/ * Gamification project update: - Survey Insights for Tor Relay Operators: https://gitlab.torproject.org/tpo/community/relays/-/issues/31 * EOL 0.3.5 removal: "Tor 0.3.5.x is unsupported beginning tomorrow, 02/01/2022. We should contact the relay operators still on it where possible to get them upgraded and then after a couple of weeks (4 maybe) remove the remaining relays from the network (see: #56 (closed) for previous work in that area)." https://gitlab.torproject.org/tpo/network-health/team/-/issues/171 * New texas relay operator group? are there others? CCCS? "We are just a small provider trying to help out the community. We believe that privacy is a fundamental right for everyone. We hope to make the internet a better place by deploying privacy based tools for everyone to use.Checkout stormycloud.org for additional information." * torservers.net reanimation continues. New website (feedback welcome) is online: https://torservers.net/ Thanks Leibi, qbi and others for the work! ### Q&A session * Who runs Tor relays today? Do we need more transparency? (no mic) * Yes, we need more transparency. Gus describes a proposed "community mapping" exercise where we learn who has links / connections to other relays. * Best providers for exit nodes? * For exits, I can recommend terrahost.no They are based in Norway, have unmetered offers and allow exits with a reduced policy in their Terms of Service * See: https://community.torproject.org/relay/community-resources/good-bad-isps/ * Would recommend avoiding hetzner, ovh, frantech, buyvm, there are too many relays there already. * Are there any plans for AS-aware tor circuit creation? (Kristian - lokodlare) Not currently -- the AS-aware Tor designs (like Raptor and following) are cool but have a bunch of big open questions and unresolved potential vulnerabilities too. So, a great research area, but comes with too many security tradeoffs currently. For a cool recent attack paper in the area, check out: https://www.freehaven.net/anonbib/#tempest-pets2018 * Are there plans on improving tor prometheus metrics? (more metrics: uptime, bandwidth, ...) It turns out the DNS metrics we had were buggy and not so useful. So there is some work to improve the accuracy / usefulness of the current metrics. https://gitlab.torproject.org/tpo/network-health/team/-/issues/175 * is C tor dead in terms of new features like this? (all dev capacity goes into rust only?) C tor is going to be deprecated over time, but the Arti roadmap involves not getting to relays for years, so there will be an interim period where we're wishing we could deprecate the C-Tor relay side yet there is no Arti relay side replacement yet. * will arti implement the control spec (compatibility with stem) no, at least not as it currently is. arti wants to be a library you can link in * Is the GeoIP location implementation for relays based on ASNs or actual country-based IP blocks. One relay operator's server is located in Japan but the AS seems to be American so the location is listed as the US. We switched from Maxmind GeoIP to IPFire in the past year. * Are there instructions for how people can report bugs to IPFire? Yes, look at https://forum.torproject.net/t/tor-relay-search-showing-location-of-some-re… We had an example where a relay operator requested a change from IPFire, and it seems to have gone surprisingly smoothly and easily. * MCH: There will be a real in-person hacker con this summer, MCH https://mch2022.org/, with at least one Tor relay operator known attending and at least one Tor developer known attending. * Is running a Snowflake proxy as useful as a (obfs4) bridge? If you have a static IP address, maybe the obfs4 bridge is smarter? Since the Snowflake model involves having many transient proxies. * Are there timelines for IPv6 only Tor or Bridge families? tor 0.4.8.x will get MyFamily support for bridges according to Nick (C tor) https://gitweb.torproject.org/torspec.git/tree/proposals/321-happy-families… * Would it be a good idea to run a web-server on the same computer as a tor bridge? Because it would introduce collateral damage? Maybe yes in theory, but in practice these days no. Russia and China block bridges by IP address in a quite automated way and they don't seem to care what else is on that computer. Mostly these censors find bridges not by looking at network traffic, but by pretending to be users showing up to bridges.torproject.org. So the censors who try to build blocklists aren't even looking much at the addresses they block. * will arti implement the control spec (compatibility with stem) * Answer: I think I've heard that it probably won't, or at least not entirely * Is it bad to have too many exit relays in one country? And how many is too many? * Norway and the US and DE seems to be quite saturated already with exit relays: NO - 37, 481 MiB/s Tor metrics numbers US - 536, 4898 MiB/s DE - 329, 8206 MiB/s See: https://metrics.torproject.org/rs.html#aggregate/cc https://nusenu.github.io/OrNetStats/ * Getting fast relays in Japan is challenging because of how we measure bandwidth weights. Is sbws moving forward? How about a newer bwauth design to make use of better geo-relay-distribution? * Will rust tor solve the multiple CPU core issue (no more multiple tor instances required on a multi core machine)? Answer: Hopefully yes, arti is multithreaded, but not as fast as C tor yet * Is stem unmaintained? Yes. * Damian no longer working on stem? I believe that Damian is no longer actively developing stem, but that he is maintaining it, in the sense that if you submit a patch he might take it, or if you submit a security issue he'll probably look at it. * How far away are we from rust tor support relays? will that also be called arti or is arti just the tor client functionality? * How far away are we from a first tor browser alpha using arti? Arti roadmap says it should be "ready for production use" in september 2022, but that's without anti-censorship stuff and onion service support. * Russia has blocked Tor relays? Tor is now pretty essential for Russians. Is speed important there? Lower latency is really useful when you're using Tor. Compare Russia to China -- China grows its internal network capacity, but not its external network capacity, and over time it becomes more fun to use Chinese services in China, and less fun to use external services in China. Will Russia go that route? We'll see. Hopefully not for a while. * How to get more Tor advocacy in each of our local areas? Seems like you read about bad people using the internet but not enough about why Tor is important. * Who runs bw authorities? How could we get one in asia? They are the services that pick weights for relays in the consensus, so they are trusted in a similar way to how directory authorities are trusted. So, right now they're run either *by* the dir auth operators, or there's a 1:1 trust relationship from dir auth operator to bwauth operator. Putting a bwauth in Asia would probably just measure all the relays as slow. And part of that is because of our sub-optimal congestion control design in Tor right now, which Mike is working on. It seems wise to wait until Mike has his fix in place, and then we can understand how much of the "geographic diversity is slow" problemwe've fixed, and how much of it remains. * SysAdmin 101 workshop Gman discusses a proposed idea on teaching relay operators about how to sysadmin properly, how to make decisions about bare metal vs VM, how to get time synchronization working right, all of the things that relay operators need better intuition about. General consensus is yes this is a good idea and could benefit a lot of people. Gman requests suggestions for most important material and topics. https://gitlab.torproject.org/tpo/community/relays/-/issues/36 * What about raising the fast relay flag threshold? The reasoning being that if you remove the really slow relays from the network, then even though there are fewer relays, average circuit performance gets better? This is actually just one of dozens of ideas we have for improving performance, and the plan is to use Mike's framework for doing a proper experiment for each idea, and measuring whether it actually helps: I think gitlab link is https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues There is a great wiki page too, listing e.g. what network characteristics to measure. Start here: https://gitlab.torproject.org/legacy/trac/-/wikis/org/roadmaps/CoreTor/Perf… and here: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Sponsor61/P… Idea for an agenda topic for next time: Mike's network-wide performance experiments, how to do experiments safely and productively on the live Tor network. -- The Tor Project Community Team Lead

3 3

new BridgeDB version using rdsys
by meskio 28 Feb '22

28 Feb '22

Hello, I have just deployed a new version of BridgeDB[0]. Now BridgeDB uses rdsys[0] as backend so it has changed how bridges are managed internally, but all the user facing pieces are (almost) the same. The distributors (email, https[1] and moat) hasn't changed and should work as before. If you are a bridge user you should not see any difference. The bridges you are already using should stay working and requesting new bridges should work as before. The move to rdsys implies that all the bridges might have changed their distribution mechanism. If you are bridge operator you might see your bridge having a different distributor mechanism in the coming hours, if you had configured your bridge with the "BridgeDistribution" option your distribution mechanism should not change and stay on what you configured. There are more few more distribution mechanisms now, this is the full list: * https. The web interface of bridgedb[0]. * moat. The API used by Tor Browser to request bridges directly from the settings. * email. Bridges distributed by bridges(a)torproject.org. * telegram. Bridges that will be distributed by the telegram bot @GetBridgesBot. * settings. A new API used to autoconfigure the circumvention mechanism depending on your geolocation. * reserved. Bridges reserved for experiments or future needs. People with bridges assigned to telegram and settings will not see much usage of their bridges yet, as those are projects we are working on but will be soon in use. If you notice any problems with the bridge distribution don't hesitate to open an issue[2] or contact me. [0] https://bridges.torproject.org [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/ [2] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

questions about raspberry pi bridges
by potlatch 22 Feb '22

22 Feb '22

Greetings, I've operated both relays and bridges for more than a decade but I'm new to the raspberry pi. I think it a real possibility for future bridge deployment en mass. I have several questions that I can't seem to work through: 1.) The tor package I get from the repository is 0.4.2.7 (obsolete). I thought it was because the pi machine had raspian for the os. So, I downloaded and installed 32-bit ubuntu server 20.04.3 instead (https://ubuntu.com/downloads/raspberry-pi) It made no difference. I changed to a new SSD to make sure all was virgin. How do I upgrade to current version of Tor for this bridge? 2.) Some of my bridges have (and some do not have) /var/lib/tor/stats folders. I am interested in the 'why' of this and also how I can install that capability on all bridge relays. The stat printout is in units of '8' and I'm sure the Russians, Egyptions, etc. do not use bridges in unit neat units. What am I reading in bridge-stats? 3.) Does Tor project state somewhere in it's docs that it's a terrible idea to give a bridge a nickname such as 'TorCuba'? It should!! potlatch Sent with [ProtonMail](https://protonmail.com/) Secure Email.

4 5

Unexpected classification with my guard relay
by Security GMVSES 22 Feb '22

22 Feb '22

Dear Mr./Mrs., As I really like the Deep Web field, and wanted to know about Tor, I decided to create a guard relay, which is this one: https://metrics.torproject.org/rs.html#details/037F39EF786C0623A059553869C0… I did all the configurations required, but after a couple of weeks, this relay is not considered a guard relay (entry relay) yet. I am contacting you because I don't understand why my relay is not considered as a guard relay (entry relay), since I already have the following flags: Fast, HSDir, Running, Stable, V2Dir, Valid. My configuration is: Nickname securitses ContactInfo securitses(a)gmail.com ORPort 443 ExitRelay 0 ExitPolicy reject *:* SocksPort 9050 AccountingStart day 0:00 AccountingMax 30 GBytes BandwidthRate 301 KBytes BandwidthBurst 350 KBytes ControlPort 9051 HashedControlPassword <Hashed_password> Thank you, Yours sincerely, Javier

4 3

snowflake incoming UDP ports
by Toralf Förster 22 Feb '22

22 Feb '22

I do simply run here ~/devel/go/src/snowflake/proxy/proxy &>>/tmp/snowflake-proxy.log & and was wondering if I have to open special UDP inbound ports ? From the stats snowflake iseems to be working: 2022/02/18 19:29:59 In the last 1h0m0s, there are 13 connections. Traffic Relayed ↑ 192 MB, ↓ 192 MB. 2022/02/18 20:29:59 In the last 1h0m0s, there are 21 connections. Traffic Relayed ↑ 451 MB, ↓ 451 MB. 2022/02/18 21:29:59 In the last 1h0m0s, there are 9 connections. Traffic Relayed ↑ 236 MB, ↓ 236 MB. but b/c I do have a rather restrict inbound firewall rule set I'm wondering about that. -- Toralf

3 4