- tor-relays - lists.torproject.org

Question on bridge hibernation
by Keifer Bly 18 Aug '24

18 Aug '24

Hi, So for my bridge at https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1… Is set to hibernate once it reaches a certain traffic level (this is to prevent massive charges to my VPS). Now that is in hibernation, when will it start again, and how would this effect how it's distributed? Are bridges that are hibernating removed from relay search? Mew to hibernation, thanks. May 14 18:49:39.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. May 14 18:49:39.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. May 14 18:49:39.000 [notice] Bootstrapped 0% (starting): Starting May 14 18:49:47.000 [notice] Starting with guard context "default" May 14 18:49:47.000 [notice] Registered server transport 'obfs4' at '[::]:8081' May 14 18:49:48.000 [notice] Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted May 14 18:49:48.000 [notice] Going dormant. Blowing away remaining connections. May 14 18:49:48.000 [notice] Delaying directory fetches: We are hibernating or shutting down. --Keifer

3 2

Archive key from deb.torproject.org was renewed!
by boldsuck 14 Aug '24

14 Aug '24

Hi @all, The package deb.torproject.org-keyring did not update the key tor-archive-keyring.gpg in /usr/share/keyrings/ only deb.torproject.org-keyring.gpg was updated. I had to replace it by hand. Renewing your key is important, otherwise you will not receive any Tor updates. One line: wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E8… | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null More Info: https://support.torproject.org/apt/tor-deb-repo/ -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

9 17

Re: [tor-relays] Archive key from deb.torproject.org was renewed - mind the * deb * !
by eff_03675549＠posteo.se 14 Aug '24

14 Aug '24

> Hi all and cheers for all your replies. > > I aimed to convey: I have no (longer) update issues from the moment I > recently found out that the change introduced beginning of this month was > NOT A CHANGE OF KEY > rather this was > AN UPDATE IN THE REPO ()we returned to a deb.only repos for all. > > And what this implies is HUGE, because most non-pro-active servers out > on the netwroks, all operators gone, who lost access to their > Unattended settlements, who trusted TOR, US ALL for respecting the > FEATURE of Unattendedness have now running server Eternally flown with > MiM-Repo-weak servers. > > I implied to ask: DO you guys realize that *Unattendness is a Feature* > to build around and not to change while asking everyone to upgrade / > Attend. > Unattended servers are abandonned, they work and their owners could > have been killed, lost interest, yet they were meant to work for us all. > > What is the share of our network that will upgrade from non-deb, > obsoleting repos, and who is going to Man-In-the=Middle that repos and > OPA (acquire for free) ALL those lone servers. > > This is a monstruous danger to the network. > > Carlos. > > > On 8/14/24 9:07 PM, Toralf Förster via tor-relays wrote: >> On 8/14/24 19:44, boldsuck wrote: >>> upgrades are running or not. And that I have to reboot because of >>> the kernel >>> upgrade or similar. (I don't like auto reboots) >> >> Ah, ok. >> I like it and have therefore unattended upgrade configured >> unconditionally for all packages [1]. >> >> Furthermore I do use needrestart to detect services and/or kernel >> requiring a reboot and do it [2]. >> >> So it works all out of the box w/o manual intervention here. >> >> [1] >> https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_common… >> >> [2] >> https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_common… >> >> >> -- >> Toralf >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > --

1 0

DOS Protection mini RFC
by pasture_clubbed242＠simplelogin.com 14 Aug '24

14 Aug '24

Since it is still all fresh in our heads, I wanted to pitch an idea real fast. No idea if it was covered at a tor meeting at some point. For bridge relay operators, such as those with very low bandwidth, it may be worth it to keep lower-than-consensus-restrictions using the DOS flags here https://2019.www.torproject.org/docs/tor-manual.html.en#DoSCircuitCreationE… -- but this might be higher maintenance though, as keeping up to date with consensus params may be needed often. Does it seem worth it or necessary to have a multiplier variable? Like bridges with low bandwidth can set, for example, DoSConsensusMultiplier 0.75 In order to lower all or select values by 75%, rounding up to the nearest whole number or the configured floor value ( perhaps DoSConsensusMultiplierFloor 2 ...?).

2 2

Reapply exit policy on reload
by boldsuck 11 Aug '24

11 Aug '24

Hi to all dear exit operators, If you are interested in applying the exit policy on reload and not by restarting tor please note: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/735#note_3051797 Quote David: "Can you give us a sense of how many exit operators use this? If there is a large enough need for this, we can evaluate this for next release but it needs to be for more than 1 operator for such feature." Related Issue: https://gitlab.torproject.org/tpo/core/tor/-/issues/40676 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

5 13

Recent Tor versions not reloading config on / ignoring HUP kill signal.
by George Hartley 10 Aug '24

10 Aug '24

Hi, I think this started with release 0.4.8.10, but both of my Tor relays no longer reload their config when doing for example: - systemctl reload tor@exit Here is the relevant part of the unit file: > [Unit]Description=Anonymizing overlay network for TCP > After=syslog.target network.target nss-lookup.target > > [Service] > Type=notify > NotifyAccess=all > ExecStartPre=/usr/bin/tor -f /etc/tor/torrc_%i --verify-config > ExecStart=/usr/bin/tor -f /etc/tor/torrc_%i > ExecReload=/bin/kill -HUP ${MAINPID} > KillSignal=SIGINT > TimeoutSec=75 > Restart=on-failure > WatchdogSec=1m > LimitNOFILE=32768 Checking with: - journalctl -u tor@exit Just tells me that systemd attempted and successfully executed the specified reload command, but the actual line from the Tor instance stating that the config has been reloaded is missing. Is anyone else experiencing this? Regards, George

2 2

Tor at Defcon 32, Las Vegas (August 8 – August 11, 2024)
by gus 09 Aug '24

09 Aug '24

Hello, A few Tor people & relay operators will be attending Defcon this year! Stop by the Tor booth to meet the team and check out new Tor merch: https://x.com/see_ess/status/1817593609123926047. Don't miss our main presentation, "Measuring the Tor network", happening on August 10th at 3pm. Measuring the Tor Network ========================= Millions of people around the world use Tor every day to protect themselves from surveillance and censorship. While the Tor Browser and its protocol are widely known, the backbone of the Tor ecosystem, its extensive network of volunteer relays, is often subject to speculation and misinformation. The Tor Project is dedicated to supporting this network and fostering a vibrant, diverse community of relay operators. This talk will focus on our efforts to maintain a healthy network and community, and detect and mitigate attacks -- all with the help of metrics and analysis of usage patterns. By illustrating how we collect safe-enough metrics for an anonymity network, we will offer insights into how we identify unusual activity and other noteworthy events on the network. We will also discuss our ongoing strategies for addressing current and future network health challenges. If you are interested in understanding the inner workings of the Tor network and its relay community and how we keep this vital ecosystem running, this talk is for you. For more info, visit: https://defcon.org/html/defcon-32/dc-32-speakers.html https://blog.torproject.org/event/defcon-2024/ cheers, Gus -- The Tor Project Community Team Lead

3 2

Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
by Sam 07 Aug '24

07 Aug '24

Hello, as tb discussed further with developers of Tor, the concept of "Reflec-Tor"s (and Exit-Nodes to be seen also as an Entry-Node) might have an impact like Snowflakes for Chat and Messaging over Tor and addresses opinions of Relay admins and university research too. Regards ---------- Forwarded message --------- Date: Di., 16. Juli 2024 um 20:36 Uhr Subject: Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes To: <tor-dev(a)lists.torproject.org> System wrote via Tor Project <noreply(a)forum.torproject.org>:Feedback: Please submit the proposal also to tor-dev: tor-dev Info PageIntroducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes https://www.reddit.com/r/TOR/comments/1e4te8m/introducing_discussing_reflec… ==============================================================Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes *Tor-Messaging: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay |* Hello, I think this belongs to this core, general, relay topic-forum, as it is also a development & community issue, request and efford, I post it here into the reddit forum for your core discussion: The idea is to add next to Bridges, Relays and Exit-Nodes also "Entry-Nodes" as "Reflec-Tor"(s) to the point of Exit-Nodes. Hence: Exit-Nodes are developed futher to be also an Entry-Node. Some may remember when gnutella got hybrid with edonkey and then also with torrent, Mike Stokes from Shareaza did that. The idea today, 20 years later, is to add some Echo-capabilities to Tor in regard of the servers for Exit and Entry. *Vision: Every (updated) Exit-Node is an Echo-Server - For a better Tor-Messaging.* What does that mean? An Echo-Server is a server for chat-messaging to send an incomming message packet again out to all connected clients at the moment. Ping-in and Ping-Out to all. That simple, that's why it is called the Echo. Like a shout in front of a forrest, all connected users can hear and get the (encrypted) shout or message or packet back from the tree wall. There are 3 software applications for Echo-Servers: - https://github.com/textbrowser/spot-on (Desktop, sercer in the Listener Tab) - https://github.com/textbrowser/smokestack (java for Android) - https://github.com/textbrowser/spot-on-lite (headless deamon for Linux) Now, the Listener function with ping in and ping out should be implemented within a Tor-Exit-Node. When it comes to Tor-Messaging, there are some pathes possible: A) Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob (Tor-proxied Chat-Server, which only accepts encrypted packets) B) Tor-Chat-Client-Alice - Echo - Tor - Tor - Echo - Tor-Chat-Client-Bob (Echo Tor-tunneled) C) Tor-Chat-Client-Alice - Echo-Server - Tor-Chat-Client-Bob (direct connection to Echo-Server with only encypted packets) The request here is to build and develop option A. That is just right now also possible, by an Exit-Node of Tor running the Echo-Server-Software on the same machine in parallel. Just the port is different. This is an idea for some might be new, but thinking Tor Messaging a bit, it comes quickly to this ideas and better soluttion. The way to connect D) Tor-Chat-Client-Alice - Hidden Onion Server v3 - Tor - Tor - Hidden Onion Server v3 - Tor-Chat-Client-Bob is the current given way for clientes like RicoChet Refresh, Quiet or Cwtch. Similar to Briar, even developers of such clients above tell the loss of messages and low reliability of the hidden to hidden path. Some of you might know, that there were use cases with missing messages in a range of 35-45 %. Don't quote me on that, but as core developers and community members you might be in contact with those who experience this. Furthermore the Messaging clients are not advanced in functionality, nor advanced in strong encryption. It would be third a long development way to got that route. It is cost effective and needs cappable developers. Some project have stamped on and made a workable client, but does that unite all our power in the sense of Tor-Messaging? Messaging needs a Vision and Statement from the Tor-Core-Developer team with a discussion in the community in that regard with honor to the individual projects and also with support for their chosen path (Model D). At the same time we have to state that it is as it is, a HTTP-Server in the middle like in Model A is faster than Model D. In the graph-path the Echo-Server in the middle handles only encrypted traffic, so it is just like another Relay. We can call it "Reflec-Tor". The only sense it to multiply incomming encrypted packets from one node to all connected nodes. With that Idea, the Messenger Spot-On could be used as a Tor-Messenger. This Messenger has stong encryption and is full of feature for messaging and also cryptography. it is like adding Firefox to Tor-Browsing, when Spot-On is added to Tor-Messaging. Something to read at the community forum: https://www.reddit.com/r/Spot_On_Encryption/ Also there is a Mobile Client for Android, which also connects to Reflec-Tors, find "Smoke" Messenger at F-Droid.org. Please, get this right, it is not about a technical view on slow and failing chat-packets to hidden servers, and it is not about those start-up clients using this inside technology, some do a good project. It is about the idea, that an Reflec-Tor mirroring and pinging back packets on the Exit-Node this hop within the path of tor is not outside, it is always fully encryted for the messaging packets and should be seen as one Tor-Path, especially if the Listener-Ping-Back function (the Echo capabilities) is build in the Exit-Node-Tor Software. Spot-On is already a Tor-Messenger - as it uses also HTTPs and it sends only encrypted packets. *A test is easy to make:* (1) Start the Tor-Browser, which has always the Port 9051 to Tor, Tor is running. Next to Surfing with Tor-Browser Firefox the Chat with Tor-Messenger Spot-On can start. (2) Start Spot-On on a webserver and create in the Listeners Tab a Listener on Port 4710. (3) Start two Spot-On Instances Alice and Bob on two Laptops, in the Neighbors Tab you connect the Webserver via Tor: Add the IP and Port 4710 to the neighbor and choose Proxy: 127.0.0.1 Port 4710. You get the the Path: Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob The idea is now to integrate this a bit more: Tor-Chat-Client-Spot-On-Alice - Tor - [Tor-Exit-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob You see, the way stays all within the Tor-Family. For sure, in case Alice does not want to use Tor, she also can message to Bob, who is behind Tor. Tor-Chat-Client-Spot-On-Alice --> [Tor-Exit-Node as Entry-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob The IP of an Entry-Node is shown in the Tor-Browser and can get a port added. Then two user can simply cata over that node. We need in times of surveillance, data retention, chat control and for sake of the needs of whistleblowser and people who want to chat privat and anonymously more decentral and open source chat server. *The mission is: Every Tor-Exit Node is an Entry-Node for Chat.* It should be not a lot of code to be added to the ports of an Exit-Node and displaying the Port of the Exit-Node in the Tor-Browser path icon. This makes sense in several effects to be discussed and developed further: - Taking the next Development Step for Tor-Messaging: BTW, A Forum about Tor-Messaging could be made as a category here in the forum please. - directly support Tor-based Messaging for the Spot-On Messaging client To be developed and discussed is, if this infra-structure could help to - support bootstrapping of Tor - support Censorship circumvention of Tor Reflec-Tors as SnowFlakes over the Messenger with EPKS - Accept, that some routing to an HTTPS internet server at the Tor-Node is faster than to an hidden onion server at the Tor Node. Well, to add some "ping-in-and-out" for an packet is what every netcat and socat under linux can do. It is a small development step to make each Tor-Exit node a free chat server for messaging, which is a big step for mankind to have a network of free messaging chat servers. Lets also see, how users and community will test and develop this messaging. So it is not only a discussion for developers, it is also a step forward the needs of the communities *for a free internet:* - *for chat and their discussions.* A few code lines to exit nodes make them a Reflec-Tor and messaging over Tor can start really decentral and open source and free. *What do you think?* does this privacy-concept bring more privacy and reliability in packet delivery to messaging with Tor? Regards

3 3

Opening metrics-api.torproject.org for testing
by Hiro 03 Aug '24

03 Aug '24

Hello everyone, As part of our redesign of the metrics pipeline, we have developed a new API that will eventually replace Onionoo: the Network Status API (aka NSA). We are now opening NSA for testing, and it can be accessed at: https://metrics-api.torproject.org. Documentation is available here: https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-…. Please note that the API may be unstable at times, and some results might be inconsistent. Onionoo will remain our primary data source for relay search at least until the end of the year. We welcome any suggestions or feedback regarding the types of information that should be included in the API. You can provide feedback by opening an issue on the repository or by replying to this email. Thank you. -hiro

4 3

Tor Metrics 'Running' flag is back for bridges who don't publish the OrPort
by lists＠for-privacy.net 30 Jul '24

30 Jul '24

I don't know if this was mentioned at the Tor Relay Meeting yesterday, if so, I missed it. ;-) A few months ago there was a recommendation to not exposing OrPort for bridges. This had the unpleasant effect that all bridges were 'red' on Tor Metrics, even though they were running perfectly fine. I noticed yesterday after the meeting that everything is 'green' again. https://metrics.torproject.org/rs.html#search/ForPrivacyNET Thank you, I believe these 6 people did that: https://gitlab.torproject.org/tpo/network-health/team/-/issues/318 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

5 7

Re: [tor-relays] Archive key from deb.torproject.org was renewed!
by boldsuck 25 Jul '24

25 Jul '24

On Donnerstag, 25. Juli 2024 01:29:41 CEST you wrote: > What was the previous key for reminder? The same ;-) > This looks like exactly the one I installed BEFORE all your messages > mentioning the requirement to update... manually. Of course, it is the same key as before. When creating PGP keys, an expiration date is defined by default. The Repo PGP key is always valid for 2 years and the expiry date has been extended for the next 2 years. > I have a problem in that I like to remove ssh before I leave my > installations, to be conscious. What do you mean exactly? 'exit', and you are logged out. > I would have to re-install yet I am pretty sure my key was also 89-ending. > > QUESTION: > > is there any one / way to tell whether my relays have the proper key > from any metrics / torproject admin / version showing up? apt update gives error message that key has expired. apt-key -list /etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg ----------------------------------------------------- pub rsa2048 2009-09-04 [SC] [expires: 2028-08-29] A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89 uid [ unknown] deb.torproject.org archive signing key sub rsa2048 2009-09-04 [S] [expires: 2026-09-09] -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 1

OT: Tor Control Protokoll ADD_ONION
by boldsuck 24 Jul '24

24 Jul '24

Hi, In the control-spec https://spec.torproject.org/control-spec/commands.html#add_onion or https://github.com/torproject/torspec/blob/main/control-spec.txt#L1777 The ADD_ONION 'Flag' include Hidden Service options: MaxStreamsCloseCircuit and MaxStreams, among others. We also want to use the PoWDefenses and IntroDoSDefense parameters. Is the control-spec outdated or is it not possible to set these parameters via Flag? -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

OT: Tor-Metrics for Hidden Services
by boldsuck 24 Jul '24

24 Jul '24

Does anyone know where I can find information about the MetricsPort output? In particular, hs introduction point and rendezvous point circ build time bucket. What do the numbers represent le="1000.00" - le="6000.00" suggested-effort value Do I understand correctly that the value goes from 0-1000? https://spec.torproject.org/hspow-spec/common-protocol.html#client-limits # HELP tor_hs_intro_circ_build_time The introduction circuit build time in milliseconds # TYPE tor_hs_intro_circ_build_time histogram tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="1000.00"} 128 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="5000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="10000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="30000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="60000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="+Inf"} 205 tor_hs_intro_circ_build_time_sum{onion="somerandomonionaddress"} 210297 tor_hs_intro_circ_build_time_count{onion="somerandomonionaddress"} 205 # HELP tor_hs_rend_circ_build_time The rendezvous circuit build time in milliseconds # TYPE tor_hs_rend_circ_build_time histogram tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="1000.00"} 14275 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="5000.00"} 24060 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="10000.00"} 24095 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="30000.00"} 24096 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="60000.00"} 24096 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="+Inf"} 24096 tor_hs_rend_circ_build_time_sum{onion="somerandomonionaddress"} 25308501 tor_hs_rend_circ_build_time_count{onion="somerandomonionaddress"} 24096 # HELP tor_hs_pow_suggested_effort Suggested effort for requests with a proof of work client puzzle # TYPE tor_hs_pow_suggested_effort gauge tor_hs_pow_suggested_effort{onion="somerandomonionaddress"} 1 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

bridges
by Earl M. Northern 22 Jul '24

22 Jul '24

obfs4 49.12.224.203:8001 8E6B9FB7914E9ECA1BD271AB33FF8D868EEA6DE5 cert=zZcPgBgVxKhmhlo2M0yLKTGkxDnSXl2372d5E0POqVMpmzu0tsIlegXR4OolUDudfD+7CA iat-mode=0 obfs4 94.131.97.25:50703 4DF9058B33F6D3E72A4397B09A40503AF51DAA04 cert=HXw+QS4SVjB9/oekpZSQcGDyoNxrp8a/mOQ14qSAuLPp5b9h6H1p4VB8008VHWPwj7vBJA iat-mode=0 obfs4 88.198.12.66:1812 7611DAC3C59A43322D774400F57FDA4D2AC0EEE2 cert=Qo94bPwOyZ9gRUJkyXFV5AhLXOPa+Ilgt8gQ+5a2Mw2NSzzvEY00FhWfeCnfSGs81CYLZA iat-mode=0

3 2

tor middle relay issue
by theyarewatching 22 Jul '24

22 Jul '24

I have had two ubuntu based tor middle relays fail.I am using a proxmox server and have tried both ubuntu server 20.04 and a fresh download of ubuntu 24.04. I follow the tor website install instructions. The results show the same no matter what version of ubuntu. "failed to start Tor(a)default.service. This is the same result with the original install and a brand new VM install on Proxmox. Any input would be greatly appreciated Thank you SDS

1 0

OOM at relay with small RAM if statistic configs are enabled
by Toralf Förster 14 Jul '24

14 Jul '24

Regarding to https://gitlab.torproject.org/tpo/core/tor/-/issues/40958 I do wonder if that issue happened for stable Tor versions too - I do run myself git HEAD only. FWIW at my bare metal relay the RAM consumption per Tor process decreased by about 0.7 GiB. -- Toralf

1 0

Hardware sizing for physical exit node
by Osservatorio Nessuno 10 Jul '24

10 Jul '24

Hi everyone, we are planning to get some hardware to run a physical Tor exit node, starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). We will also route a /24 on it, so we will have large availability of addresses to run multiple instances. We have been running a few exit nodes so far, but never on our own hardware. Which is the bandwith limit per core/Tore instance? Or what can we expect to be the bottleneck? Due to some other requirements we need for some experiments (SFP ports, coreboot support, etc) we can mainly choose between these 2 CPUs: Intel i5-1235U Intel i7-1255U The cost between the two models is significant enough in our case to pick the i7 only if it's really useful. In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is it?). Should this allow us to saturate the uplink? To summarize, with this bandwith, this hardware and a /24 how many Tor exit nodes should be ideal to run considering that each of them could have their own address? Thanks!

5 4

Seeking Advice on Running Multiple Tor Relays or A Bridge
by Alessandro Greco 07 Jul '24

07 Jul '24

Hello Tor Community, I have some experience running a Tor relay, and I am now interested in setting up another one. I plan to do this using my home internet connection, which is an FTTH line with bandwidth up to 2 Gbps. I have read that it is possible to run multiple relays on the same node, but I am unsure how to configure this. Additionally, I am curious about what would be most beneficial for the Tor network today: a highly resilient bridge or multiple relays managed from the same node? Is it feasible to operate both at the same time? This is probably not the best idea since the bridge's IP address would be public, right? I am looking for guidance on the best course of action to support the Tor community. Thank you in advance for your assistance,Aleff.

4 5

Re: [tor-relays] Seeking Advice on Running Multiple Tor Relays or A Bridge
by 0tpcqovw＠duck.com 07 Jul '24

07 Jul '24

For what it's worth, in addition to my Tor Bridge Relay, I also run two Snowflake Proxies on my home LAN. Malcolm On 6 July 2024 19:14:23 GMT-03:00, "Gary C. New via tor-relays" <tor-relays_at_lists.torproject.org_0tpcqovw(a)duck.com> wrote: >Alessandro, > >I would recommend running bridges (opposed to relays) on a home network to avoid browing issues with your bank, news, etc as these entities often block Tor relays and not bridges. >Respectfully, > >Gary > > On Saturday, July 6, 2024, 3:07:52 PM MDT, Roger Dingledine <arma(a)torproject.org> wrote: > > On Sat, Jul 06, 2024 at 06:34:37PM +0000, Alessandro Greco via tor-relays wrote: >> I have some experience running a Tor relay, and I am now interested in setting up another one. I plan to do this using my home internet connection, which is an FTTH line with bandwidth up to 2 Gbps. > >Thanks for running a relay! > >> I have read that it is possible to run multiple relays on the same node, but I am unsure how to configure this. > >If you're using the tor deb (e.g. on Debian or Ubuntu), it comes with >a tool to set up multiple tors. "man tor-instance-create" to get started. > >There is also the possibility of using the fancy automated >deployment tools that some of the bigger relay operators here >use, which probably only makes sense if you are already familiar >with these automation tools (a popular one based on ansible: >https://github.com/nusenu/ansible-relayor ). > >In either case, make sure you have enough memory in your system to >handle each Tor relay: relays can use 1 or 2 gigabytes of memory each >during normal operation, but when the network is under load it can go >much higher than that. > >> Additionally, I am curious about what would be most beneficial for the Tor network today: a highly resilient bridge or multiple relays managed from the same node? > >If you have the bandwidth (which it sounds like you do), the multiple >fast relays will be much more useful to the network. > >See also https://2019.www.torproject.org/docs/faq#RelayOrBridge > >> Is it feasible to operate both at the same time? This is probably not the best idea since the bridge's IP address would be public, right? > >It is technically possible yes, but as you say, having a public relay >on the IP address will undermine the effectiveness of your bridge on >that IP address. > >The same logic is also why we don't recommend running two different >kinds of bridges on a single IP address: if one of them gets discovered >and the censor blocks by IP address, then the other will stop working too. > >> I am looking for guidance on the best course of action to support the Tor community. >> Thank you in advance for your assistance,Aleff. > >Thanks for wanting to help! > >--Roger > >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

1 0

Quick Assist Technology and Tor?
by mail＠nothingtohide.nl 25 Jun '24

25 Jun '24

Hi o/, During the Tor Operator Meetup I asked about Quick Assist Technology (QAT) support and was asked to bring it to the tor-relays mailing list so the network team can take a look at the question. In 2025 we're going to build one or more new servers and we're looking in to optimizing the performance per watt ratio since some of our current servers are rather power hungry ;-). I'm wondering whether QAT works for Tor to offload compression, hashing and encryption. In theory, looking at the nature of Tor (a lot encryption), this could result in a huge performance boost of 100-300% (based on other hashing, cryptographic and compression offload benchmarks). Support for QAT also has improved considerably over the years so many programs/workloads already work nicely with it, but I'm not sure about Tor. It looks like Tor uses [1] RSA-1024, AES-CBC, AES-CTR, Curve25519, Ed25519, SHA1, AES256, AES3-256. Most (no Curve- and Ed25519) should in theory also work with QAT [2] (although I guess only a few would impact performance significantly when offloaded). But the question is: does it really work? If not, what would be needed to make it work? Are there Tor operators who already utilize QAT? Does the Network Team have some insight in to this? :) Some of the potential advantages when comparing a similar amount of traffic: - Lower power consumption (much cheaper to run in expensive European countries). - Less CPU cycles required (= cheaper CPUs). - Less heat/cooling required (easier to put in distribution boxes and other small places). - Smaller physical footprint (easier to put in distribution boxes and other small places). - Alleviates some of the issues and challenges caused by Tor's single threaded architecture by effectively increasing bandwidth per CPU core considerably. With regards, tornth [1] https://spec.torproject.org/tor-spec/preliminaries.html?highlight=cipher#ci… [2] https://www.intel.com/content/www/us/en/support/articles/000093843/technolo…

4 4

Why should we avoid adding bridges fingerprints in MyFamily?
by Edward Cage 23 Jun '24

23 Jun '24

Hi all, Quick question about the fingerprints of our bridges. It's clearly written in torrc that we should not include them in MyFamily. I don't well understand why, especially because: - Every bridge, and their fingerprints, are publicly listed on Tor Metrics; - The contact email is disclosed for each of them, and it allows our bridges and relays to be easily linked to a same operator. (or should we use a different email address for each bridge?) Best regards

2 1

Next Tor Relay Operator Meetup - June 22, 2024 at 19 UTC
by gus 22 Jun '24

22 Jun '24

Hello, Please save the date: the next Tor Relay Operator will happen Saturday, June 22 at 19 UTC! We're still working on the agenda for this meetup, however feel free to add your topics directly to this pad or just reply to the mailing list: https://pad.riseup.net/p/tor-relayop-june22-meetup-keep ## Agenda 1. Announcements - EOL work: bridges running 0.4.7.x were rejected from the network: https://lists.torproject.org/pipermail/tor-relays/2024-June/021678.html - Snowflake extension issue: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/142 - Farahavar directory authority is back! https://gitlab.torproject.org/tpo/core/tor/-/commit/39ba9ce0d7913ceb53fc1f1… 2. Network Health - Reports of relays ddos & ongoing onion services overload 3. Policy and proposals discussion: - https://gitlab.torproject.org/tpo/community/policies/-/issues/22 4. Next events - Tor presence at DEFCON, Las Vegas - Summer break & next Tor Relay Operator online meetup 5. Questions & Answers <add your questions here> ## How to join us Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: June 22, 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before. cheers, Gus -- The Tor Project Community Team Lead

2 2

Tor non-exit list
by Carsten Otto 22 Jun '24

22 Jun '24

Hi Dan, For reference: https://www.dan.me.uk/dnsbl https://www.dan.me.uk/tornodes https://www.dan.me.uk/torlist/?full First of all, thank you for your tools and other contributions. The mere fact that your DNS blocklists are used by countless vendors should be a compliment in itself, and I'd be happy to have that much impact with my own projects. As you already state on your own site ("Please think carefully before choosing to use this list for blocking purposes"), your non-exit Tor relay list is a bit unusual. I'm running ftp.halifax.rwth-aachen.de, a major file mirror serving around 30 TByte of data at around 4 GBit/sec (on average). Recently, we added Tor relays on the same IP address, and your list correctly picked this up (137.226.34.46). Now, I'm writing as this caused quite a lot of mayhem. Several "security" appliance vendors didn't "think carefully" before adding your non-exit list to their devices. Among those are Arbor Prevail, Check Point, Ubiquiti (UniFi) - feel free to search for "ET TOR Known Tor Relay/Router (Not Exit) Node" to see the effect of this. In addition to private users making use of such devices, several banks/corporations/institutions started blocking our IP address, causing some frustration with us and their admins, as their Linux/Jenkins/... updates suddenly stopped working. As you might have guessed, changing "security" configurations (even if they may be wrong or questionable) is quite a challenge, and in some cases the (motivated) admins weren't unable to fix this issue on their end. As you seem to be well aware of what Tor is, what an exit relay does and what a non-exit relay does, would you be willing to retire the non-exit blocklist (at least the part that can be used for automated blocks)? I'd argue that the current setup does more harm than good (assuming you agree that Tor is a good thing in general). I'd be happy to discuss pros and cons, but ultimately that's your decision to make. Thanks Carsten -- Dr. Carsten Otto http://verify.rwth-aachen.de/otto/

5 6

Relay usage dropped 9x when enabling UFW. What UFW rules do other relay operators enact?
by admin＠likogan.dev 19 Jun '24

19 Jun '24

Hello all, I'm running relay 292FCACE773DC259B799914A23BE65A6A6178E8F and have noticed traffic drops when enabling UFW. Around 2024-01-15, I enabled UFW on this server. I noticed a 9x drop in traffic (10.88M -> 1.708M), and coughed it up to relay weirdness. This is about when my relays Guard status would randomly drop every few weeks. I finally got fed up with this huge drop in traffic on 2024-06-11 and was about to reinstall my server OS. This is when I decided to disable UFW and found that my traffic went back over a few days (2.215M -> 8.948M). Here are my tor-related UFW rules; To Action From -- ------ ---- [ 3] 9001 ALLOW IN Anywhere [11] 9001 (v6) ALLOW IN Anywhere (v6) I'm really confused how UFW firewalled most, but not all, of my relays traffic. What UFW rules do other relay operators enact? Thanks, Likogan

3 2

Re: [tor-relays] Relay usage dropped 9x when enabling UFW. What UFW rules > do other relay operators enact?
by zorc 19 Jun '24

19 Jun '24

Hi Likogan, > What UFW rules do other relay operators enact? I'm running 4CEAFCE5841C0DAE30164B4F59452F7F4D818A67 on Linux Mint 21.3 (should be close to Ubuntu Jammy) with UFW enabled, and don't have any issues. I have the same two rules for Tor as you do. I can imagine three things: 1. To me it looks like you have other rules before your Tor rules. Are any of them rate limiting? 2. I don't run an exit node, so I don't know how UFW would behave in that case. 3. Do you have logging rules? I once had issues with my router running out of CPU due to some logging rules being triggered by Tor-related traffic (potentially malicious). Maybe UFW could achieve something similar? Hope that helps. Cheers, zorc

1 0