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

recommended way to run 0.4.7 on armhf?
by ilf 26 Nov '23

26 Nov '23

What's the recommended way to run 0.4.7 on armhf? > The package repository [deb.torproject.org] does not offer 32-bit ARM > architecture (armhf) images (yet). https://support.torproject.org/apt/tor-deb-repo/ Debian has 0.4.7 in bullseye-backports. But Raspbian doesn't have bullseye-backports: http://raspbian.raspberrypi.org/raspbian/dists/ -- ilf If you upload your address book to "the cloud", I don't want to be in it.

3 6

security update for obfs4proxy
by meskio 11 Jan '23

11 Jan '23

Hello, The latest version of obfs4proxy (0.0.14) comes with an important security fix. If you are running a obfs4 Tor bridge please upgrade as soon as possible. If you use debian you can find the Debian package in stable-backports: https://packages.debian.org/stable-backports/obfs4proxy If you use docker you'll find the latest version in docker hub: https://hub.docker.com/r/thetorproject/obfs4-bridge/ Or you can find the source code in the upstream repository: https://gitlab.com/yawning/obfs4 If you need help upgrading your relay, please use this mailing list or the Tor Forum: https://forum.torproject.net/c/support/relay-operator/17 We appreciate a lot your effort and time! Thank you -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

4 12

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

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

04 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

Need a little assistance with a relay
by Ronvau 05 Nov '22

05 Nov '22

Hello Tor, I am looking to set up a relay but have not been successful yet. ALthough I believe I followed instructions, the relay "Walton" does not appear to be functioning as I would expect. I was using SNAP as a vehicle to launch the relay but no luck there as it fails as well. Is there anyone that can work with me to get this relay up and online?? Thank you.Ron V.

3 3

Re: [tor-relays] security update for obfs4proxy
by Toralf Förster 04 Nov '22

04 Nov '22

On 10/14/22 19:09, meskio wrote: > The upstream changelog is here: > https://gitlab.com/yawning/obfs4/-/blob/master/ChangeLog > But I understand is not easy to understand what the problem is from that > changelog. Indeed. BTW the fix was made 5 weeks ago, so I do assume, the (eg. Debian) package needed time to stabilize, or ? -- Toralf

3 3

My bridge has no distribution mechanism
by Keifer Bly 30 Oct '22

30 Oct '22

https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1… Hey, So my bridge, listed above, says it has no distribution mechanism. Does this mean it is not currently being used? Thank you. --Keifer

1 0

DoS attacks -- status update
by Georg Koppen 28 Oct '22

28 Oct '22

Hello everyone! It's been a while since we last provided some update on this mailing list about our ongoing work fighting several DoS attacks. We can use the attached graph about detected overload over the last couple of months to show what is going on and what we do/plan to do about it. The first noteworthy incident on that graph is the sharp rise in overloaded non-exit nodes since the middle of July caused by a drop of onionskins[1] which the relay's available CPU/memory can't handle anymore. There are currently two ideas we are working on to cope with such a flood of onionskins: 1. Developing a Proof of Work (PoW) system to has a rate-limitation knob rejecting the load of onionskins while letting legitimate ones through.[2] We still need to solve some design issues (feel free to help!) but hope to have that feature integrated into Tor soon. 2. Relay operators started to experiment with iptables/nftables rules and having the right ones available might be a good stopgap approach against the onionskin related DoS. We are coordinating that effort[3], so we have something available to propose to the wider community, which is kept up-to-date and limits the risks of traffic overblocking. Feel free to help as well with that effort. The other noteworthy incident started around September 13 when exit nodes began to get overloaded (while the other DoS was and is still ongoing). Unfortunately, that exit related DoS is heavily impacting our users' experience as can be seen in our OnionPerf data[4]. While we are still investigating the nature of that DoS attack it turns out that blocking particular IP addresses with ExitPolicy rules seems to help on exit nodes this is tested on. The Artikel10 exit node operators provided even a script recently[5] to help with that (much appreciated, thanks!). This approach is highly experimental at this point and it might help us at least to come up with an actual design idea to counter that particular exit DoS. Thanks, Georg [1] For information about overload in general and what "drop of onionskins" means, see: https://support.torproject.org/relay-operators/#relay-bridge-overloaded. It contains as well a guide on how to enable MetricsPort monitoring yourself so you see the actual metrics of your own relay. [2] https://gitlab.torproject.org/tpo/core/tor/-/issues/40634 [3] https://gitlab.torproject.org/tpo/community/support/-/issues/40093 [4] https://metrics.torproject.org/torperf.html [5] https://lists.torproject.org/pipermail/tor-relays/2022-October/020848.html

1 0

MetricsPort: tor_relay_connections_total type confusion
by nat＠danwin1210.de 28 Oct '22

28 Oct '22

Hello David, again, thanks for your work on adding more metrics to tor's MetricsPort! Many relay operators will love this and documentation will be useful [1]. I reported https://gitlab.torproject.org/tpo/core/tor/-/issues/40699 which got closed yesterday, but there was likely a misunderstanding and the changes did not solve the underlying issue. The core issue is: The metric called tor_relay_connections(_total) [2][3] contains a mix of different types (gauge, counter). When mixing types in a single metric, the TYPE definition will always be wrong for one or the other value. For example grafana will show this if you use a counter metric without rate(): "Selected metric is a counter. Consider calculating rate of counter by adding rate()." It is a best practice to avoid mixing different types in a single metric. >From the prometheus best practices [4]: "As a rule of thumb, either the sum() or the avg() over all dimensions of a given metric should be meaningful (though not necessarily useful). If it is not meaningful, split the data up into multiple metrics. For example, having the capacity of various queues in one metric is good, while mixing the capacity of a queue with the current number of elements in the queue is not." An idea to address the underlying issue: One connection metric for counter and one for gauge: - tor_relay_connections_total for counters, like the current label state="created" - tor_relay_connections for gauge metrics, like the current label state="opened". "rejected" also appears to be a gauge metric. Another nice feature of these metrics would be to have a label for what type of system is connecting (src="relay", src="non-relay") - more on that in yesterday's email. A tool by toralf [4] also shows these and uses the source IP but tor itself does not need to look at the source IP to determine the type, something discussed in last week's relay operator meetup. best regards, nat [1] https://gitlab.torproject.org/tpo/web/support/-/issues/312 [2] https://gitlab.torproject.org/tpo/core/tor/-/commit/06a26f18727d3831339c138… [3] https://gitlab.torproject.org/tpo/core/tor/-/commit/6d40e980fb149549bbef5d9… [4] https://prometheus.io/docs/practices/naming/

2 2

Upcoming OpenSSL 3 security bugfix release
by Georg Koppen 28 Oct '22

28 Oct '22

Hello relay operators! If you are running OpenSSL 3 please be aware that you might need to upgrade it to 3.0.7 as fast as possible on next Tuesday (Nov 1). In an announcement[1] it got said 3.0.7 fixes a CRITICAL security issue. Operators running on the 1.1 series are fine as far as we know so far. Georg [1] https://www.openwall.com/lists/oss-security/2022/10/25/4

1 0