- tor-relays - lists.torproject.org

Storing ed25519_master_id_secret_key[_encrypted] on a smartcard?
by telekobold 04 Mar '23

04 Mar '23

Dear fellow relay operators, currently, I'm operating a Tor relay (Middle/Guard) and a Tor Bridge. Offline keys [1],[2] are a good way to secure a Tor relay, but I'm wondering if there is a standard way or something like a hacking guide how to store your ed25519_master_id_secret_key[_encrypted] on a smartcard or hardware token like a Nitrokey or Yubikey? This would even be more secure than storing it on a "normal" USB device. Unfortunately I have not found much about this on the internet. Kind regards telekobold [1] https://support.torproject.org/relay-operators/offline-ed25519/ [2] https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity/Offl…

1 1

RFC: does a private exit would work?
by Toralf Förster 04 Mar '23

04 Mar '23

tl;dr; restricted access + usage of an exit longer: An exit is sooner or later abused. A reduced exit policy does not prevent that. What about setup a tor exit relay with 'PublishServerDescriptor = 0' ? Having an access line like for bridges would restrict the access. An alternative could be a port knockig + iptables solution. Objections and comments are welcome. -- Toralf

5 5

Preferred range for ephemeral ports
by binarynoise 03 Mar '23

03 Mar '23

Hello everyone, I just set up a snowflake proxy on my pi at home. Unfortunately I can only forward 255 ports to my pi (at once, or is there a way to trick my Fritz!box into allowing more?). Which is the preferred range for -ephemeral-ports-range when it needs to be restricted to allow the most users to connect? Is 60000:60250 ok? Greetings binarynoise

2 1

removing tor versions from "recommended versions" before they reach EOL
by nusenu 01 Mar '23

01 Mar '23

Hi, the tor 0.4.5.x end of live versions are still on the recommended versions list: https://consensus-health.torproject.org/#recommendedversions > consensus client-versions 0.4.5.6, 0.4.5.7, 0.4.5.8, 0.4.5.9, 0.4.5.10, 0.4.5.11, 0.4.5.12, 0.4.5.14, 0.4.5.15, 0.4.5.16, 0.4.7.7, 0.4.7.8, 0.4.7.10, 0.4.7.11, 0.4.7.12, 0.4.7.13 > server-versions 0.4.5.6, 0.4.5.7, 0.4.5.8, 0.4.5.9, 0.4.5.10, 0.4.5.11, 0.4.5.12, 0.4.5.14, 0.4.5.15, 0.4.5.16, 0.4.7.7, 0.4.7.8, 0.4.7.10, 0.4.7.11, 0.4.7.12, 0.4.7.13 it would probably be better to stop recommending tor versions a month before they reach their eol date so relay operators get to see a log entry and have some time to react. kind regards, nusenu -- https://nusenu.github.io

2 1

relay configuration not allowing optimal performance
by Relayer 26 Feb '23

26 Feb '23

I'm running a tor relay on some older hardware that I didn't want to discard when I could still put it so good use. Some details of the box are: -- CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz -- RAM: 4GB -- ARCH: x86_64 -- HDD: 250GB -- OS: Ubuntu 22.04.1 I originally configured a single Tor instance IPv4 to run as a relay only (not as an exit, nor hosting a hidden service). I am also using the iptables rules from https://github.com/Enkidu-6/tor-ddos to minimize DDOS overhead (please advise if there are alternatives or additions to this). My original config seemed ok until I started seeing my CPU and RAM maxing out consistently so I throttled back with the following in my torrc: RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps) MaxAdvertisedBandwidth 1 MB My RAM usage now is only about 50% or marginally less of my total available. Here's how the metrics look lately: https://metrics.torproject.org/rs.html#details/38939B45237BA84941C74836349C… As you can see, the throughput rated dropped in half (that's when the graph drops on 2023-02-09). However, the volume continued to decline. Additionally, I'm unclear why my Middle Probability and Consensus Weight have both dropped to near 0%. Are those, in fact, where I want them? I'm monitoring with nyx and see I get some traffic through with no apparent errors or warnings. I am NOT seeing the CPU spikes any longer but I don't think I'm giving the most with my hardware. Questions: 1.) Is my tor service now misconfigured and not utilizing my hardware as best it could? 2.) Should my Consensus Weight and/or Middle Probability be higher? 3.) Should I consider running two tor instances? Nyx log snippet: 07:59:32 [NOTICE] Heartbeat: DoS mitigation since startup: 7 circuits killed with too many cells, 591 circuits rejected, 2 marked addresses, 0 marked addresses for max queue, 0 same address concurrent │ connections rejected, 0 connections rejected, 0 single hop clients refused, 19166 INTRODUCE2 rejected. [1 duplicate hidden] │ 07:59:32 [NOTICE] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 57982 v4 │ connections; initiated 116266 and received 356623 v5 connections. │ 07:59:32 [NOTICE] Circuit handshake stats since last time: 3/3 TAP, 44849/44849 NTor. [1 duplicate hidden] │ 07:59:32 [NOTICE] While not bootstrapping, fetched this many bytes: 194128391 (server descriptor fetch); 7140 (server descriptor upload); 17539422 (consensus network-status fetch); 1794 (authority cert │ fetch); 2111765 (microdescriptor fetch) │ 07:59:32 [NOTICE] Heartbeat: Tor's uptime is 10 days 23:58 hours, with 179 circuits open. I've sent 34.83 GB and received 35.63 GB. I've received 444762 connections on IPv4 and 0 on IPv6. I've made │ 254336 connections with IPv4 and 0 with IPv6. [1 duplicate hidden] │ 01:59:32 [NOTICE] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 56651 v4 │ connections; initiated 114326 and received 347071 v5 connections. │ 01:59:32 [NOTICE] While not bootstrapping, fetched this many bytes: 189431170 (server descriptor fetch); 7140 (server descriptor upload); 17131743 (consensus network-status fetch); 1794 (authority cert │ fetch); 2068377 (microdescriptor fetch) Thanks. Relayer1974

2 1

Re: [tor-relays] Frantech (was Re: Confusing bridge signs)
by Jeff Teitel 26 Feb '23

26 Feb '23

On Fri, Feb 24, 2023 at 12:10 AM Marco wrote: > Yes, Frantech should actually be avoided. But in Miami there are few Tor > relays. A SLICE 512 for $2.00/m or $20.00/y is sufficient for a bridge. > https://buyvm.net/kvm-dedicated-server-slices/ Why should Frantech be avoided? Jeff Teitel

2 1

Questions about Tor consensus weight & swag
by shruub 19 Feb '23

19 Feb '23

Hello, so my relay regulary gets overloaded, for what I can only assume is an hardware issue, (which I can't upgrade rn) since I already applied the tor anti ddos scripts. It seems to be able to recover, however with a lower Consensus Weight. I also (stupidly) tried to have a cron restarting my tor daemon daily which also resulted in the latter. So I wonder, if there is any way to have a relay run more stable and I suppose with a somewhat higher consensus weight (I can only asssume making some further changes in advertising bandwidth etc. My second question(s) is/are concerning the tor swag (I hope that's allowed to ask here). Firstly, what is the actual Speed requirement? In the tor ecosystem, every unit is MBs, and only on the swag site its KBs. But if my calculations are correct, 500KBs = 500000Bs = 0.5MBs which doesn't really make sence, imo(but I probably misscalculated somewhere). Secondly, does running mean it's uptime (aka Last Restarted) or the Time it was first seen? Sorry for the wall of text for not much information, and thanks a lot in advance for your replies! Best, shruub

4 5

disable moderation on tor-relays again?
by nusenu 15 Feb '23

15 Feb '23

Hi, can we try to disable moderation on this list again and see how it goes? If it gets out of hand you can always move back to a moderated mode or a mode where the first email of a sender is moderated. kind regards, nusenu -- https://nusenu.github.io

4 4

Use OutboundBindAddress on multi-instance tor servers
by nusenu 13 Feb '23

13 Feb '23

Hi, to reduce the risk that your multi-instance tor relay setup triggers false-positive filter thresholds on other relays, I recommend you make use of the OutboundBindAddress (or OutboundBindAddressOR) option and set it to the same IP as in the ORPort line. This will ensure that the outbound source IP will be the same when connecting to relays. The man page is not clear what tor's default without that setting is but I guess that would leave it to the OS to pick the source IP and that could result in all your tor's using the same source IP. relayor users are covered by default, no further action required. https://github.com/nusenu/ansible-relayor/blob/2bc62d62f85b62c51a38d9caa893… kind regards, nusenu -- https://nusenu.github.io

4 5

publish current AuthDirMaxServersPerAddr limit?
by nusenu 12 Feb '23

12 Feb '23

Hi, would it be possible to publish the currently enforced value of AuthDirMaxServersPerAddr on some tpo website? Maybe consensus-health.tpo? kind regards, nusenu -- https://nusenu.github.io

3 2