December 2021 - tor-relays - lists.torproject.org

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

19 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

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 related talks @ rC3
by nusenu 17 Jan '22

17 Jan '22

in chronological order: ------------------------------------------------------ title: Towards a more Trustworthy Tor Network when: 2021-12-28, 17:00 CET where: https://streaming.media.ccc.de/rc3/csh primary target audience: - Tor user - Tor relay operators - onion service operators - and everyone that cares about Tor ------------------------------------------------------ title: The Tor Project - State of the Onion when: 2021-12-28, 18:00 CET where: https://streaming.media.ccc.de/rc3/csh ------------------------------------------------------ -- https://nusenu.github.io

2 3

Bridge showing offline
by Eddie 12 Jan '22

12 Jan '22

Looking at tor metrics, one of my bridges is showing as off-line: B080140DC1BAB5B86D1CE5A4CA2EF64F20282440 However, the log isn't showing any issues: Oct 14 00:00:28.000 [notice] Tor 0.4.5.8 opening new log file. Oct 14 00:00:28.000 [notice] Configured hibernation. This interval began at 2021-10-14 00:00:00; the scheduled wake-up time was 2021-10-14 00:00:00; we expect to exhaust our quota for this interval around 2021-10-15 00:00:00; the next interval begins at 2021-10-15 00:00:00 (all times local) Oct 14 01:49:40.000 [notice] Heartbeat: Tor's uptime is 124 days 6:00 hours, with 0 circuits open. I've sent 907.23 GB and received 922.28 GB. I've received 63052 connections on IPv4 and 8375 on IPv6. I've made 512684 connections with IPv4 and 100974 with IPv6. Oct 14 01:49:40.000 [notice] While not bootstrapping, fetched this many bytes: 1801791624 (server descriptor fetch); 175792 (server descriptor upload); 221750347 (consensus network-status fetch); 10974 (authority cert fetch); 19905655 (microdescriptor fetch) Oct 14 01:49:40.000 [notice] Heartbeat: Accounting enabled. Sent: 140.52 MB, Received: 140.69 MB, Used: 281.21 MB / 200.00 GB, Rule: sum. The current accounting interval ends on 2021-10-15 00:00:00, in 22:10 hours. Oct 14 01:49:40.000 [notice] Heartbeat: In the last 6 hours, I have seen 14 unique clients. Initially I thought of a previous issue I had with IPv6 connectivity, but don't think this is the problem here as the 2nd bridge on the same server is showing on-line. Also an IPv6 port scan shows the ports for both bridges as accessible. Ideas ?? Cheers.

5 8

General overload -> DNS timeouts
by Intrepid Ibex 07 Jan '22

07 Jan '22

Hi everybody, I am new to tor (as server operator) and try to support the network by operating an exit node. Machine is running Ubuntu 20.04 - Tor 0.4.6.8. nyx is giving me a notive every 10 minutes or so: [NOTICE] General overload -> DNS timeouts (6) fraction 1.4742% is above threshold of 1.0000% DNS on this machine however works perfectly. I told my tor browser to use my specific exit node, everything works fine. Node is running since 4 days now. Load is as expected. Thanks in advance for any help! Ibex \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io

13 25

Relay operators meetup @ rC3
by Stefan Leibfarth 29 Dec '21

29 Dec '21

Greetings relay operators, the annual Tor relay operators meetup will be tomorrow (28th) at 2200 UTC+1. No rC3 ticket required, I'll post the public link here as soon as it's available. Looking forward to meeting you Leibi

4 4

[Censorship in Russia] More of my bridges got blocked
by spaceoddity＠disroot.org 29 Dec '21

29 Dec '21

Hello Tor people, just me chipping in about recent event. Today, I discovered that somewhere around Dec, 22, all three of my recently launched bridges have been censored on at least one network (MegaFon Moscow AS25159). Metrics show a drastic traffic drop in the range of Dec, 21-23 for all three bridges. Investigating further, I discovered (using tcptraceroute/nc) that all three hosts started responding with RSTs to all of their open ports (not only bridge ports but SSH and other recently opened ports too). NATd source IP address was unchanged from my usual one in every case. One of the bridges had distribution method set to HTTPS, and the other two were distributed via Moat. All ran recent Tor 0.4.6.8 Docker image. NB: One of the bridges has incorrect 'First seen' date on the metrics portal - it displays '2021-12-25' despite being launched several days prior. To summarize: 1. Bridge blocking happens via the common 'fast RST' method 2. It happened relatively quickly (all bridges are less than 10 days uptime by now). 3. Somehow, all three of my recently launched bridges were blacklisted despite using different ASs/hosters/countries for each. Is it a coincidence, or it's because Moat prefers to hand out newer bridges first, or due to something else entirely? Also, I can not rule out that some step in my distribution chain was compromised -- I gave out these bridges privately to a few friends. -- Best regards, Space Oddity.

3 4

Incorrect "first seen" info
by a tor op 28 Dec '21

28 Dec '21

I notice that the "first seen" info on my obfs4 bridge status page on tor atlas / metrics all of a sudden is incorrect, by years. Not sure if it's something that introduced itself with latest update or what. The various graphs on traffic and users are still correct through. A tor op

3 3

[Censorship in Russia] Make HTTPS/Moat captcha more complex?
by spaceoddity＠disroot.org 27 Dec '21

27 Dec '21

Hi there. I was thinking, what could be the ways Russian authorities could get bridges to block. One of the obvious ways to do this is to grab bridges from Moat/HTTPS, but since that would require solving a captcha, this would indicate its strength is insufficient, or they are able to crowdsource/mass solve somehow. The other thought is an attack via email. Can we do something with it, what do you think? -- Best regards, Space Oddity.

8 10

Moving relay to other VPS
by bobby stickel 27 Dec '21

27 Dec '21

4 4