Re: [tor-relays] Recent rejection of relays
Georg Koppen: Jonas via tor-relays: Where is this criteria documented? I am not sure what criteria you mean but we have our bad-relay criteria[1] documented at our wiki and keep fingerprints we reject due to attacks we noticed there as well[2]. It seems the tor project, or its designated volunteers, are increasing controlling and managing the network. In the Swiss Federation and EU this turns the tor project into an "online service provider" or "online platform" and subjects one to all sorts of regulations and compliance regimes. We already get enough requests from the police regarding relays hosted in our datacenters. Shall we point them at tor as the network operator? The Tor Project is not running the network. There is an additional point that is important here that I forgot (sorry for that and thanks to a little bird reminding me): yes, we working on hunting malicious relays tracked some of those relays for a while which I mentioned in my previous mail and we reached out to some of their operators. However, the relays did not got rejected by us at the end of the day, but rather by a majority of directory authorities. Those authorities are a central part of our project, too, but I think it's important to point out that the "we" in my original mail was supposed to point to different groups within the Tor Project which might not have been clear enough. Georg It's comprised of relays run mostly by volunteers. I am actually not really sure either what you are proposing to be honest. Shall we just keep the relays attacking our users in the network instead? Georg [snip] [1] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-rejecting-bad-relays [2] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Rejected-fingerprints-found-in-attacks -- Original Message -- On Wed, November 10, 2021 at 8:59 AM, Georg Koppen wrote: Hello everyone! Some of you might have noticed that there is a visible drop of relays on our consensus-health website.[1] The reason for that is that we kicked roughly 600 non-exit relays out of the network yesterday. In fact, only a small fraction of them had the guard flag, so the vast majority were middle-only relays. We don't have any evidence that these relays were doing any attack, but there are attacks possible which relays could perform from the middle position. Therefore, we decided we'd remove those relays for our users' safety sake. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
-- Original Message -- On Sat, October 9, 2021 at 7:10 AM, Georg Koppen wrote: Thanks for the proposal it provides good food for thought. You are right there is the MR on Gitlab now but I don't think your proposal is torspec material. Nor do I think a lot of relay operators are watching the discussion there. However, as they are the ones who are most affected by the proposal it's smart to find a better place for discussing its ideas. Hence this thread on tor-relays@. ---response starts here--- As a bridge operator, I stopped the plan on running relays due to the identity requirements. I could easily run thousands of bsd-based (personal choice) across many ASes or cause many to appear through steep discounts at my employer. However, providing proof of identity or anything which ties to my real world identity is a non-starter. Prior conversations with The Tor Project Inc have been encouraging about running many relays and/or offer discounts to relay operators through my employer. I'm greatly concerned with proposals like this. I fully understand the concern over "malicious relays". What little I understand of the published literature, there are far more accurate, lower resource attacks against tor than running many modified relays. This proposal seems to come from a desire of power and control over the network, not actually improving "anonymity" for users. Dose this run into legal regulations in the EU and other places that will clearly demonstrate that "control" means the tor project is actively managing the network? The secondary concern is the safety of that identity data collected by the tor project or its designated "authorities". It builds a network graph of relay operators and their ties to the tor project. This network graph makes it trivial to figure out whom to surveil and where to apply pressure to do actions to benefit "the state". The controlled shutdown of v2 onions raised many eyebrows in our legal dept. It de facto states the tor project is controlling the network and operating as an online service provider or online platform. These are my current concerns and thoughts. Feedback and pointers to more reading are welcomed. Merci, Jonas ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Recent rejection of relays
Jonas via tor-relays: Where is this criteria documented? I am not sure what criteria you mean but we have our bad-relay criteria[1] documented at our wiki and keep fingerprints we reject due to attacks we noticed there as well[2]. It seems the tor project, or its designated volunteers, are increasing controlling and managing the network. In the Swiss Federation and EU this turns the tor project into an "online service provider" or "online platform" and subjects one to all sorts of regulations and compliance regimes. We already get enough requests from the police regarding relays hosted in our datacenters. Shall we point them at tor as the network operator? The Tor Project is not running the network. It's comprised of relays run mostly by volunteers. I am actually not really sure either what you are proposing to be honest. Shall we just keep the relays attacking our users in the network instead? Georg [snip] [1] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-rejecting-bad-relays [2] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Rejected-fingerprints-found-in-attacks -- Original Message -- On Wed, November 10, 2021 at 8:59 AM, Georg Koppen wrote: Hello everyone! Some of you might have noticed that there is a visible drop of relays on our consensus-health website.[1] The reason for that is that we kicked roughly 600 non-exit relays out of the network yesterday. In fact, only a small fraction of them had the guard flag, so the vast majority were middle-only relays. We don't have any evidence that these relays were doing any attack, but there are attacks possible which relays could perform from the middle position. Therefore, we decided we'd remove those relays for our users' safety sake. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Recent rejection of relays
Where is this criteria documented? It seems the tor project, or its designated volunteers, are increasing controlling and managing the network. In the Swiss Federation and EU this turns the tor project into an "online service provider" or "online platform" and subjects one to all sorts of regulations and compliance regimes. We already get enough requests from the police regarding relays hosted in our datacenters. Shall we point them at tor as the network operator? Jonas -- Original Message -- On Wed, November 10, 2021 at 8:59 AM, Georg Koppen wrote: Hello everyone! Some of you might have noticed that there is a visible drop of relays on our consensus-health website.[1] The reason for that is that we kicked roughly 600 non-exit relays out of the network yesterday. In fact, only a small fraction of them had the guard flag, so the vast majority were middle-only relays. We don't have any evidence that these relays were doing any attack, but there are attacks possible which relays could perform from the middle position. Therefore, we decided we'd remove those relays for our users' safety sake. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Question about IPv6
> I have three relays running Hardened BSD hosted at Frantech. They do > not offer support for setting up IPv6. By Frantech do you mean buyvm.net ? If it works the same way as buyvm, your VM should have a single public IPv6 address. You can request a /48 or /56 prefix to be routed to that public IPv6. Or do you actually need help to have it setup on Hardened BSD? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Question about IPv6
Does the provider offer IPv6? If not, then there is no further progress possible.If they do, this is pretty accurate to get started, https://www.vultr.com/docs/configuring-ipv6-on-freebsdJonas-- Original Message --On Wed, November 10, 2021 at 12:40 AM, xplato via tor-relaystor-relays@lists.torproject.org wrote:Greetings,I have three relays running Hardened BSD hosted at Frantech. They do not offer support for setting up IPv6. I am not sure how to accomplish this and wondered if anyone would have insight into setting this up? I have not found much in the way of instruction. A resource that provides instructions would be much appreciated.Kindly,DanSent with ProtonMail Secure Email.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Crashed Relay
On 02 Nov (18:20:31), sysmanager7 via tor-relays wrote: > I was notified by Uptime Robot that relay 1 of 3 had been shut down. > Unfortunately I found this out 12 hours after the fact. > guard flag is lost. > > journalctl -u tor@default > > Nov 01 01:03:18 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: I learned some more > directory information, but not enough to build a circuit: We need more > microdescrors: we have 6178/6618, and can only build 49% of likely paths. (We > have 99% of guards bw, 50% of midpoint bw, and 98% of exit bw = 49% of path > bw.) > ptors: we have 6178/6618, and can only build 49% of likely paths. (We have > 99% of guards bw, 50% of midpoint bw, and 98% of exit bw = 49% of path bw.) > ived 4371.61 GB. I've received 7345604 connections on IPv4 and 0 on IPv6. > I've made 677780 connections with IPv4 and 0 with IPv6. > Nov 01 06:47:26 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Interrupt: we have > stopped accepting new connections, and will shut down in 30 seconds. > Interrupt aga> > Nov 01 06:47:26 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Delaying directory > fetches: We are hibernating or shutting down. > Nov 01 06:47:56 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Clean shutdown > finished. Exiting. > Nov 01 06:48:04 ubuntu-s-1vcpu-2gb-nyc1-01 systemd[1]: tor@default.service: > Succeeded. > Nov 01 06:48:04 ubuntu-s-1vcpu-2gb-nyc1-01 systemd[1]: Stopped Anonymizing > overlay network for TCP. So this log indicate that your "tor" received a SIGINT and did a clean shutdown. Not sure why that happened but it happened... :S David -- fsQzn9293ONauAEmTyBPCVFpFcCWrEEXYnVe8hcOgOo= signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Questions about my tor node
Bobby, I run a Tor relay on dual core 256MB devices with a 250Gb fiber connection and they are adequate to operate as a fast middle relay. Monitor your relay on https://metrics.torproject.org/ to verify. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Wednesday, November 10, 2021, 2:40:19 AM MST, Bobby wrote: Hello I'm running a tor node and I paid for a VPS for the express purposes of running that node. I have configured it to use almost all of the bandwidth of the VPS and then to allow bursts to use all of the bandwidth I have also set it to serve directory requests. The server also has 1GB of ram and 1 CPU core. Is this good enough to be helpful in the tor network? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hardware requirements for a fast Tor relay
The following are some of the more important config options that I use for such a small middle relay: # Tor: A non-exit relay should be able to handle 7000 concurrent connections ulimit -n 65535 DirCache 0 ExitRelay 0 # Note: The default MaxMeminQueues is 3/4 (i.e., 192MB) of Total System Memory (i.e., 256MB) # Uncomment the following line to limit Tor to use less System Memory (i.e., 128MB) MaxMemInQueues 192 MB Log notice file /tmp/torlog Log notice syslog RunAsDaemon 1 DataDirectory /tmp/tor/torrc.d/.tordb AvoidDiskWrites 1 — This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Wednesday, November 10, 2021, 2:36:13 AM MST, failing.flyaway443--- via tor-relays wrote: Hi Gary, thank you for your response. I think I just worry too much. I watched my relay all the time today, I had bandwidth usage of 30MB/s at times and HTOP showed me a Load average of 0.29/0.29/0.30. I know that this is totally fine for a dual core. The relay is up and running for 3 days and 8 hours now and I already moved ~700GB in each direction (upload/download). I was just concerned because the VPS started crashing after 2 weeks solid uptime, but I should have set stricter bandwith limits. You can't really compare a VM with a root server, I don't think this will happen again. It's ok for me to invest a little more and have a fast and stable relay this way. The traffic was capped with the VPS plan, this was obviously a big disadvantage, now I can use as much traffic as I want with a 2,5Gbit link (1Gbit guaranteed). For your info, the most important lines of my config: SocksPort 0 Log notice file /var/log... Log debug file /var/log... ORPort 443 RelayBandwithRate 1000Mbit RelayBandwithBurst 1000Mbit Exit policy reject *:* ContactInfo & Nickname set, of course... ;) Is there anything I should change? Thanks for your help! Best Regards... ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hardware requirements for a fast Tor relay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm sorry that I now spam the mailing list, but I made a mistake. I'm of course NOT logging at debug level, it's just one logfile (notices.log). I logged debug when I was running the relay on the VPS because I wanted to know why it crashed all the time, but all that happened was that my 20TB SSD was maxed out within two hours and I had to reboot to get rid of the old logfiles. My bad, please don't think I write a debug log, that's completely pointless. Why would I. I rented a pretty expensive root server because I think Tor is really important and I want to relay as much traffic as possible, not to log debug messages. This was obviously not correct, but the rest of my torrc looks as described above. By the way, my relay has now around 4000 incoming and 4000 outgoing connections and a throughput of almost 1TB/day, and the load averages are still below .40. Everything looks good. :) Have a nice day, everyone! -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEElcZnZFMJSyKcTts0q6Mz3/Qy4d0FAmGLxa0ACgkQq6Mz3/Qy 4d1vJhAArWytI9hG6iGIvVzUP6lOgLMCEVfn4KBiFzq0iGqr2ex+utWIt8gek3SX Bm9McRbicgDUSzbnrHJrPzKxrpYvvtABbApyDZDSOEwgSXeaUcE2J8jhk20fOA6u tLFf7S+ON88KW8HkwNIkqSFmRifp3dZEBOapFZnBfgREwu19qxg1iyYZfJHDIMd6 4vWzI5oo2D1iFTyCDZllduqEURZNgZRfwtNk8ydfOje9X0QMkHgzy4fECCNgcYdY to+1BbYxY2lT34+1aLoRnnyA2yLykYI2ivRNx+IyD9X/QCKq+3sV+xjRvyOH39r7 Tmvg8NTNuZCiEwi9JCIJlRynrFk3HgUTbCT87iK8PGMTG6TimnBvFKUfKQMwIicD 1YrLQ30hSjTnetRbyLT0B7gd+h+CkDg6ssi0j6eKV0urP6PTipnr19OJeBZ3kZbw j+a3qipxy3mNIp9dW9d+ZBzhV+jtrDUMKUpjqHUkUEEdNH060TSMyYMBwCf7/dgH Ft8FWgTcLtX9dohx/CAHfQ+8rsa/wYEuLnXgc3AXibof9VZaTMKz5iDkhUwOnCoA 0528RNKLH+Rf4CoMOCycjqW0k1svPX9oAXoOgX0GQz/1DnocA4DEs+wVPJmr6dR+ mcHwDiKlOd5ksARl+fivmHurUE+ULzhI8l+Cdhr+Wi7NzVzuZ5U= =s8hY -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Recent rejection of relays
Hi, At the end of the year, we will have a Tor relay operator meetup during the rC3[1]. It's an online event. Leibi will share the invitation here, when the date and time are confirmed. Please also join our matrix/IRC channel: #tor-relays:matrix.org (or #tor-relays - irc.oftc.net) And our new Tor Forum: https://forum.torproject.net/ Thanks for running relays! Gus [1] https://events.ccc.de/2021/11/08/rc3-2021-nowhere/ On Tue, Nov 09, 2021 at 10:06:28PM +, t...@nullvoid.me wrote: > What community updates and organizations are there outside this mailing list? > > I operate the small nullvoid family of relays and want to grow it in the near > future but not miss out or misconfigure and cause problems for the rest of > the team. > > > On November 9, 2021 8:09:40 PM UTC, Georg Koppen wrote: > > > >Finally, anyone running relays: try to get connected to the community so we > >can build some trust among each other. That seems to be an essential part in > >our long-term strategy to fight bad relays trying to enter our network. > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- The Tor Project Community Team Lead signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] General overload -> DNS timeouts
nusenu: Anders Trier Olesen: The Tor relay guide should recommend running your recursive resolver (unbound) on a different IP than your exit: https://community.torproject.org/relay/setup/exit/ yes, that is a good idea, here is a PR for it: https://github.com/torproject/community/pull/169/files Thanks. I created a ticket[1] for it in our bug tracker, so your PR does not fall through the cracks. Georg [1] https://gitlab.torproject.org/tpo/web/community/-/issues/239 OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Questions about my tor node
Hello I'm running a tor node and I paid for a VPS for the express purposes of running that node. I have configured it to use almost all of the bandwidth of the VPS and then to allow bursts to use all of the bandwidth I have also set it to serve directory requests. The server also has 1GB of ram and 1 CPU core. Is this good enough to be helpful in the tor network? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Question about IPv6
Greetings, I have three relays running Hardened BSD hosted at Frantech. They do not offer support for setting up IPv6. I am not sure how to accomplish this and wondered if anyone would have insight into setting this up? I have not found much in the way of instruction. A resource that provides instructions would be much appreciated. Kindly, Dan Sent with [ProtonMail](https://protonmail.com) Secure Email.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Recent rejection of relays
What community updates and organizations are there outside this mailing list? I operate the small nullvoid family of relays and want to grow it in the near future but not miss out or misconfigure and cause problems for the rest of the team. On November 9, 2021 8:09:40 PM UTC, Georg Koppen wrote: > >Finally, anyone running relays: try to get connected to the community so we >can build some trust among each other. That seems to be an essential part in >our long-term strategy to fight bad relays trying to enter our network. > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hardware requirements for a fast Tor relay
I just read this research paper, maybe it's worth thinking about some kind of implementation of this approach some time in the future. It's an interesting read anyway. uwspace.uwaterloo.ca/bitstream/handle/10012/16108/Engler_Steven.pdf Regards ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hardware requirements for a fast Tor relay
Hi Gary, thank you for your response. I think I just worry too much. I watched my relay all the time today, I had bandwidth usage of 30MB/s at times and HTOP showed me a Load average of 0.29/0.29/0.30. I know that this is totally fine for a dual core. The relay is up and running for 3 days and 8 hours now and I already moved ~700GB in each direction (upload/download). I was just concerned because the VPS started crashing after 2 weeks solid uptime, but I should have set stricter bandwith limits. You can't really compare a VM with a root server, I don't think this will happen again. It's ok for me to invest a little more and have a fast and stable relay this way. The traffic was capped with the VPS plan, this was obviously a big disadvantage, now I can use as much traffic as I want with a 2,5Gbit link (1Gbit guaranteed). For your info, the most important lines of my config: SocksPort 0 Log notice file /var/log... Log debug file /var/log... ORPort 443 RelayBandwithRate 1000Mbit RelayBandwithBurst 1000Mbit Exit policy reject *:* ContactInfo & Nickname set, of course... ;) Is there anything I should change? Thanks for your help! Best Regards... ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
