- tor-relays - lists.torproject.org

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 06 Jul '24

06 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