- tor-relays - lists.torproject.org

Relay suddenly pushing very little traffic
by Zachary 13 Sep '24

13 Sep '24

Hello all, I am the operator of relay AS11796EntryMiddle. This is a strategically placed relay on a 106.4 mbps internet connection with no fluctuations in bandwidth available to it. The relay has very good peering to major backbone providers such as Arelion which allows many people to access it with minimal network hops, which is why I host it in that ISP’s network. Over the past six months, I typically saw traffic ranging between 15 and 70mbps. Now suddenly the relay seemingly can’t efficiently process traffic, the advertised bandwidth has tanked, and it’s pushing virtually no data. I am running Tor 4.8.12 installed from the official Tor repositories in Ubuntu 22.04 with OR port 9001. The entire network is an EdgeRouter plugged into WAN and then a firewall rule letting traffic hit the host for Tor. The relay is indeed working, but everyday it seems that less and less traffic is getting through (this is very evident on Tor metrics.) TCP connections are not exhausted so I’m pretty confused what’s going on. Any thoughts? Not trying to waste anyone’s time just don’t want this relay to go to waste. Thanks, Zachary

1 0

Supporting TOR: Seeking Affordable and Reliable Server Providers in Eastern Europe
by coal_norm_0v＠icloud.com 12 Sep '24

12 Sep '24

Hello everyone, I’ve been a fan of Tor for many years now, and my affinity for anonymity naturally extends to other interests, such as Monero… 😉 I’ve successfully rallied like-minded individuals who have generously supported our cause through various grants, and we’ve even received a government subsidy from the Czech Republic to promote freedom of speech in oppressive regimes. With a substantial sum of money at our disposal, we’ve chosen to allocate a portion to support the TOR project. Currently, we operate around 60 servers. Our main challenge, unsurprisingly, is with exit servers. Convincing providers to overlook automatic complaint notifications has proven quite tricky. From our original 30 exit nodes, we’re down to about 5—the rest had to be shifted to relay nodes. We could switch them to well-known operators like RDP.sh, but they already host a large number of exit nodes, and we prefer to encourage network diversity. We’ve initiated something akin to a cost-sharing model for enabling our servers to run exit nodes, but it hasn’t made a significant impact. We want to spend our funds wisely to support Tor. Do any of you have suggestions for good, affordable providers in less conventional locations (e.g., Eastern Europe like Poland, Hungary, Ukraine)? Thanks for any ideas, Alex https://tor.foundation

5 5

Artikel 5 e.V. - Another police raid in Germany - general assembly on Sep 21st 2024
by Artikel 5 e.V. 09 Sep '24

09 Sep '24

Hello to all list-reading entities! On Aug 16th 2024 German police considered it once again appropriate to raid the home&office at the registered address of our organization. The first raid was 2017. There are obviously still people working in German law enforcement today, who think that harassing a node-operator NGO would somehow lead to the de-anonymization of individual tor users. At least that is what they claim in the paperwork. As with the first time, the raid team was fortunately a bit better educated and acted significantly more reasonable than the non-technical people applying for the raid and the judge signing it off. So again, no hardware was seized. Apart from one burnt (middle relay) node and some billing paperwork for the exit node this was all about, the team left the house after one and a half hours with mostly empty hands. We intend to legally challenge the search warrant to make sure that this does not happen again (but this is not what this email here is about). These were once again one and a half hours with armed police in a personal living room, threatening to de-facto kill a livelihood and software business (carrying a truckload hardware away) of an non-profit board member to force cooperation. As a consequence, I am personally no longer willing to provide my personal address&office-space as registered address for our non-profit/NGO as long as we risk more raids by running exit nodes. That is a risk I am just no longer willing to take anymore. Artikel 5 e.V. is now calling for a general assembly on Sep 21st 2024. We are looking for new board members (who take over and organize a new registered address and keep running exits) or discuss ALL alternative options. These options include "just stop running exits" or even the most drastic step of liquidating the entire organization and distribution of the remaining budget to other German organizations (that would have to qualify under our non-profit by-laws). Assembly time&location details can be found at https://artikel5ev.de/ We intend to provide a stream primarily for our members but also for interested parties who can not attend in person. The event/stream will however be in German only. Details for the stream will be made available on the website on short notice before the event starts. If you plan to attend in person, an upfront email would be appreciated, so we can pick the right room to set things up. Thank you! Regards, Gero Kühn for Artikel 5 e.V.

3 2

Next Tor Relay Operator Meetup - September 7th, 2024 at 19UTC
by gus 08 Sep '24

08 Sep '24

Hi, Save the date: the next Tor Relay Operator will happen Saturday, September 7th, 2024 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-sept7th-meetup-keep ## Agenda 1. Announcements 2. 2024 Elections & Anti-censorship news 3. Network health updates - New Metrics Network Status API 4. OTF relay operator survey summary/presentation 5. Questions & Answers <add your question below> ## How to join us Meetup details: - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: September 7th, 2024 - 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

3 5

simple instructions to the expiredkey issue, pls.?
by code9n＠pm.me 06 Sep '24

06 Sep '24

Hi, I know I should have sorted this some weeks ago but can anyone tell me a simple method of dealing with the: bullseye InRelease: The following signatures were invalid: EXPKEYSIG 74A941BA219EC810 deb.torproject.org archive signing key issue, please? Thanks.

4 4

Bridge node configurations and where to find them (semi quote)
by Alessandro Greco 31 Aug '24

31 Aug '24

Dear all, In the past, I set up a middle relay node, and today I am looking to experiment with configuring a Bridge node to support the Tor project and its community. Since this is a very sensitive task, I decided to reach out to you to ensure that the setup is correct and that the configuration does not pose any risks to users who connect. First, I will summarize the `torrc` configuration file (I have removed the ports as they differ from the standard ones): ``` BridgeRelay 1 ORPort <port> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:<port> ExtORPort auto ExitPolicy reject *:* ``` I have set two limits on the connections: ``` BandwidthRate 300 MBytes # I want to determine how much bandwidth I can allocate without impacting my network usage. IPv4Only ``` As for the information settings, I have used the usual `ContactInfo` and `Nickname`. While reading the `torrc` documentation, I discovered the Sandbox feature, which is still in development. In this regard, I would like to ask whether using experimental features like this on Bridge nodes is advisable or not. Personally, I would find a feature like this very useful. Should an anti DDoS system be configured? I wanted to ask how I can further contribute to the Tor Project's research, as I have read that there are "Statistics" features that allow the collection of useful information for the developer community. I have two main questions about this: 1. Is it advisable to use experimental features or those that collect information on a Bridge node (assuming there is a difference between a Bridge, a Guard/Middle relay, and an Exit Node)? 2. If the answer to the first question is yes, what are all the features that I can include in the `torrc` file to passively support research within the Tor Project? Finally, I would like to ask what information should be kept confidential when managing a Bridge. For example, I know for sure that it is important to keep the IP address confidential to avoid the risk of being blacklisted, but are there any other pieces of information that need to be protected? To ensure that a Bridge node can be restarted on a different machine, which files need to be preserved? Are they the same as those for a standard relay (i.e., the private key), or are there additional files that need to be securely stored? Thank you for your support and guidance. Best regards, Aleff --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

3 6

Request for Tor to support armhf architecture
by Landon 30 Aug '24

30 Aug '24

I am running a Raspberry Pi Raspbian OS (debian) mini computer. Tor software does not support this hardware without me having to compile it myself for my platform. Which I don't know how to do. My specific APT error message says this: N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'https://deb.torproject.org/torproject.org bookworm InRelease' doesn't support architecture 'armhf' The Raspberry Pi is a perfect computer to run Tor because it has 8 GB RAM, is tiny, only uses a max of 25 watts of power and works great as a network server. Plus, I don't have to leave my big power hungry desktop computer on all the time to run Tor. Raspberry Pi info page: https://www.raspberrypi.com/products/raspberry-pi-5/ Landon

3 4

a couple noob questions
by observatory123 27 Aug '24

27 Aug '24

Dear fellow relay operators, I've been hosting a tor relay on a VPS (strato) for a couple days now. I've never done this before, so I have a couple of questions: - Is it normal for my relay to only use up only about 2 MB/s after nearly 5 days of uptime despite bandwidth speed tests done with speedtest-cli generally reporting significantly higher bandwidth? - Is it normal for my relay to advertise 7.37 MiB/s on its relay search page despite bandwidth speed tests done with speedtest-cli generally reporting significantly higher bandwidth? - Do I have to mark somewhere that I'm hosting the tor relay on a VPS (which means technically a company also has control over the relay)? - Is this mailing list a good place to ask these questions? Or am I reaching too many people by doing this? When I say I performed a bandwidth test, I mean I performed a bandwidth test with the speedtest-cli debian package. The test generally tells me I have about 217 MB/s download speed and 113 MB/s upload speed. The nickname of my relay is observatory123 and its fingerprint is: 45431BF8AB66C673942C1E344BB520625CE5F817 Kind regards, observatory123

8 9

Re: [tor-relays] [network-health] help metrics torpoject
by George Hartley 21 Aug '24

21 Aug '24

Hi, don't worry, a relay will be removed from metrics 7 days after you shut it down. Sincerely, George On Sunday, August 18th, 2024 at 8:49 AM, kop kop <a5654505(a)gmail.com> wrote: > Good afternoon. how can I delete an entry in https://metrics.torproject.org/rs.html#search/134 > about fargo node? > I didn’t think twice and deployed this relay from my home network and now I’m afraid of persecution from the authorities. I ask for help.

1 0

Re: [tor-relays] DDOS alerts from my provider
by eff_03675549＠posteo.se 21 Aug '24

21 Aug '24

Hi Rafo, My apologies for the late reply in your request for the code on banning tor exits into *GUARDS or middle-relays* * * * * rm ../../etc/cron.d/updateSSHkey echo "0 0 * * * root wget -P /root/scriptsremote/ https://check.torproject.org/torbulkexitlist" > ../../etc/cron.d/blacklistTORexits echo "1 1 * * * root sed 's/^/-A ufw-before-input -s /; s/$/ -j DROP/' /root/scriptsremote/torbulkexitlist" >> ../../etc/cron.d/blacklistTORexits echo "2 1 * * * root sed -i '/# End required lines/r /root/scriptsremote/torbulkexitlist' /etc/ufw/before.rules" >> ../../etc/cron.d/blacklistTORexits echo "3 1 * * * root rm /root/scriptsremote/torbulkexitlist" >> ../../etc/cron.d/blacklistTORexits apt install -y fail2ban rm ../../etc/fail2ban/jail.d/sshd.conf touch ../../etc/fail2ban/jail.d/sshd.conf echo "[sshd]" > ../../etc/fail2ban/jail.d/sshd.conf echo "enabled = true" >> ../../etc/fail2ban/jail.d/sshd.conf echo "port = 11218" >> ../../etc/fail2ban/jail.d/sshd.conf echo "filter = sshd" >> ../../etc/fail2ban/jail.d/sshd.conf echo "logpath = /var/log/auth.log" >> ../../etc/fail2ban/jail.d/sshd.conf echo "maxretry = 5" >> ../../etc/fail2ban/jail.d/sshd.conf echo "bantime = 24h" >> ../../etc/fail2ban/jail.d/sshd.conf echo "bantime.increment = true" >> ../../etc/fail2ban/jail.d/sshd.conf echo "bantime.factor = 24" >> ../../etc/fail2ban/jail.d/sshd.conf echo "bantime.maxtime = 52w" >> ../../etc/fail2ban/jail.d/sshd.conf Here I hope this is well received, Carlos. On 7/10/24 1:19 AM, god-gave-you-mouth-ears-eyes-so-enjoy(a)posteo.net wrote: > > Hi Rafo, > > > I have a pre-defined fail2ban (jail) script that does all the job of > banning any tor-EXIT -dynamically updated via cron- from attempting > access when this helps. > > This is meant for Debian, > > the synthax could do with fedora (perhaps a few code adaptation). > > let me know when this is of interest. > > > Carlos. > > On 7/8/24 7:34 PM, Rafo (r4fo.com) via tor-relays wrote: >> Hi, >> I have been running a relay for a few months now without any >> problems. But this week I’ve received 2 DDoS alerts from my provider >> (Netcup), both are ~3 gigabits. They seem to be coming from other Tor >> relays. >> I’m running an Invidious like instance on my server (which uses >> around 600 megabits) but I have a 2.5 gigabit port. So I configured >> my Tor relay to use 300-400 megabits. >> I’m not sure where that 3 gigabit of data comes from. >> I have lowered my advertised bandwidth to 100 megabits, would that be >> enough to prevent these kind of issues? >> >> >> Kind regards, >> Rafo >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- > Updated every second week. > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > xjMEZfy9NxYJKwYBBAHaRw8BAQdAManzdqpnuQkafKwGP49famHD40TRuz3tlk2S > 6x9w7afNP0d1c3QgT09ITlRFUiA8Z29kLWdhdmUteW91LW1vdXRoLWVhcnMtZXll > cy1zby1lbmpveUBwb3N0ZW8ubmV0PsKPBBMWCAA3FiEEEAD7hg5vFuAk80AxAZJk > LcbaZlUFAmX8vTcFCQATxoACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRABkmQtxtpm > VRErAQDPkO6rew8L0fv+YkObGBGL58dxZtWbELZqDjICDi5A6QD/QC4978BycOFq > ZAx/N9ihgNLRm6Sg1EUupAoaVMcDVA7OOARl/L04EgorBgEEAZdVAQUBAQdA0Xrh > XPXwikKTr7amFdFv57VCWtansLWJCnYqFAVWYmADAQgHwn4EGBYIACYWIQQQAPuG > Dm8W4CTzQDEBkmQtxtpmVQUCZfy9OAUJABPGgAIbDAAKCRABkmQtxtpmVfxdAQDL > TRwNnIeZ//Y4kahWP+WWS7qb6EmM1mCtjRc3IadSDgD+Nh1xGFt00AQtG+oMKF/J > GwnLbMda6bMdvCIXN+U1LQw= > =z8PX > -----END PGP PUBLIC KEY BLOCK----- -- PGP updated every second week : please actualize our communication every time.

2 1

DMARC helps prevent Tor-exit from being abused for email SPAM.
by boldsuck 20 Aug '24

20 Aug '24

Hi @all, I thought DMARC was unimportant for a small domain, but I played around with it a few days ago. There are some DMARC monitor sites that you can use for free & I was surprised when I saw that in 2-3 days about 1500 emails were sent via my exit subdomains. Then I set DKIM and SPF to strict adkim=s; aspf=s; and DMARC subdomain policy to reject sp=reject; Since then, emails about Tor-exits have dropped to 0 ;-) -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

DDOS alerts from my provider
by Rafo (r4fo.com) 20 Aug '24

20 Aug '24

Hi,I have been running a relay for a few months now without any problems. But this week I’ve received 2 DDoS alerts from my provider (Netcup), both are ~3 gigabits. They seem to be coming from other Tor relays.I’m running an Invidious like instance on my server (which uses around 600 megabits) but I have a 2.5 gigabit port. So I configured my Tor relay to use 300-400 megabits.I’m not sure where that 3 gigabit of data comes from.I have lowered my advertised bandwidth to 100 megabits, would that be enough to prevent these kind of issues?Kind regards,Rafo

6 12

An Internet backbone blocklisted my Tor server!
by Landon 20 Aug '24

20 Aug '24

TL;DR... Write down your Tor server's GATEWAY IP address. if your server goes offline, try tracerouting to your Tor server's gateway IP address as well as your Tor server's IP address! You might be surprised by what you see! And also install MTR... It is helpful!! Here's the detailed explanation on how you can perform MTR command on your computer and server https://support.gcore.com/hc/en-us/articles/19864311353105-How-to-run-MTR-o… Okay, here is what happened... Late last night I tried to log into my VPS where I am running my Tor bridge server. I was unable to connect. It seemed like my server was offline so I filed a ticket with my service provider which is GCore Labs ( https://hosting.gcorelabs.com/ ) (I've been running my Tor bridge on their server for 4 years.) However, I discovered that my server was not actually down. I was able to login to my server using VNC in the control panel. I did some network diagnostics to diagnose my network connectivity problem. Even though my server was running, it was essentially offline. I could not ping or traceroute from my server to 8.8.8.8 or 1.1.1.1. It looked like there was a network outage. I used some looking glass servers to see what was going on as well. Here was what I discovered... From the Internet, I could ping and traceroute my VPS server's gateway (which is one hop away from my server) but if I tried to ping or traceroute using my server's actual IP address then this is where it stopped working. The culprit was Cogent Communications' routers! [AS174] As soon as packets destined for my server's IP address reached Cogent's routers, they were dropped!! However, packets destined for my server's gateway went through! >From what I understand, my server's gateway is the physical machine running my VPS. How can a packet reach my server's gateway, but not reach my server? It's not like the packet was not making it from my gateway to my server. The packets were being dropped at the edge of Cogent's network [AS174]. I also ran a traceroute on Cogents own looking glass server ( https://cogentco.com/en/looking-glass ) and when I used my server's IP, it showed nothing but when I used my gateway IP it worked! Tell me how that is possible if Cogent was not blocking my server's IP address? I sent Cogent an email asking why they were blocking my server's IP address in their routers. By the time they got back to me, my server was back online and was not being blocked. They sent me an email saying that packets going to my server were routing through their network, which by that time they were. What is so interesting about my Tor server that a major network backbone blocks my IP? If you look at my Tor server's usage graphs, you can see where it is periodically offline. Look at the 6 month graph for the average number of connected clients and you will see places where it is not online. https://metrics.torproject.org/rs.html#details/4A0B065DB3CF807C6910DFEF6D9C… I bet the reason that my server periodically goes offline is because it is being blocked and not because it is actually offline! Have you ever had this happen to your server? Landon

4 3

Re: [tor-relays] [tor-dev] 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 George Hartley 19 Aug '24

19 Aug '24

Hello, > 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 %. Sorry, but this is just not the case from my experience - it may take a while to fetch the descriptor of the hidden service, but once a TCP connection is established, aka. the ACK packet has been received, there should be no problems with packet-loss, this is one of the core features of TCP: Retransmission on various conditions. I also hosted a hidden IRC server, as well as a Tor hidden service on my grandmothers laptop, to be able to SSH in through Tor and troubleshoot problems. Experienced no packet loss, unless a relay in the circuit suddenly went offline. If you want, I can measure packet loss from various locations (Northern Europe, East Europe, and New York, USA). Also, to improve latency and throughput, you could make the server a one hop hidden server by enabling: > HiddenServiceSingleHopMode This way the looking up the server is faster, but clients remain anonymous using a normal 3-hop circuit. I don't think we need extra code for this, you could just build your app using the programming language of your desire and use the existing network. That's what I was doing with my ~200 user IRC server, and it worked fine, even while being hosted at home at a limited uplink of 15 Mbps, which now got upgraded to 30 Mbps. Unfortunately fiber is not an option, so we have to rely on 60+ years old copper wires maintained by Telecom, I have a quite fancy industrial router with modem software and capabilities, and we still use VDSL2 17a G.Vector (ITU G.993.5). I do however own a virtual machine machine on my friends colocated server at DataWagon, they are very exit friendly, zero abuse so far, I believe they just redirect abuse mails to /dev/null or something.. lol. Anyway, point is that I never encountered packet loss, and even if, the protocol would compensate for it. This became kind of a rant while I'm at work, so if it's not that useful, Im sorry. Regards, George On Wednesday, August 14th, 2024 at 9:12 AM, Sam <alleestrasse100(a)gmail.com> wrote: > System wrote via Tor Project <noreply(a)forum.torproject.org>: > ============================================================ > > Feedback: Please submit the proposal also to tor-dev: tor-dev Info Page > ======================================================================= > > Introducing & 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

2 2

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 15 Aug '24

15 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 15 Aug '24

15 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 15 Aug '24

15 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