- tor-relays - lists.torproject.org

Authority Nodes
by Vitor Milagres 06 Jul '20

06 Jul '20

Hi, I see the Authority Nodes are located only in North America and Europe. I would like to contribute to the TOR network as much as possible. I am currently running a node and I would like to make it an Authority Node as well. I am from Brazil and I believe it would possibly be a good idea to have a new Authority Node in South America. What are the requirements? What should I do to become one of them? FYI, the node I am running is 79DFB0E1D79D1306AF03A4B094C55A576989ABD1 Thanks, Vitor Milagres

8 9

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale malicious actors
by niftybunny 05 Jul '20

05 Jul '20

How many of us do not have our own IP space and can already be verified by this? > On 5. Jul 2020, at 17:54, nusenu <nusenu-lists(a)riseup.net> wrote: > > Hi, > > I'm currently writing a follow-up blog post to [1] about a large scale malicious tor exit relay operator > that did run more than 23% of the Tor network's exit capacity (May 2020) before (some) of it got reported to the bad-relays team and > subsequently removed from the network by the Tor directory authorities. > After the initial removal the malicious actor quickly restored its activities and > was back at >20% of the Tor network's exit capacity within weeks (June 2020). > > [1] https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-t… > > To prevent this from happening over and over again > I'm proposing two simple but to some extend effective relay requirements > to make malicious relay operations more expensive, time consuming, > less sustainable and more risky for such actors: > > a) require a verified email address for the exit or guard relay flag. > (automated verification, many relays) > > b) require a verified physical address for large operators (>=0.5% exit or guard probability) > (manual verification, low number of operators). > It is not required that the address is public or stored after it got verified. > For details see bellow [2]. > > 0.5% exit probability is currently about 500-600 Mbit/s of advertised bandwidth. > > > Q: How many operators would be affected by the physical address verification requirement if we use 0.5% as a threshold? > A: About 30 operators. > > There are currently about 18 exit [3] and 12 guard operators that run >0.5% exit/guard capacity > if we ignore the fresh exit groups from 2020. > Most exit operators (14 out of these 18) are organizations with public addresses or have their address published in WHOIS > anyway. > > At the end of the upcoming blog post I'd like to give people some idea as to how much support this proposal has. > > Please let me know if you find this idea to limit attackers useful, especially if you are a long term relay operator, > one of the 30 operators running >=0.5% exit/guard capacity, a Tor directory authority operator or part of The Torproject. > > > thanks for your support to fight malicious tor relays! > nusenu > -- > https://mastodon.social/@nusenu > > > [2] > Physical address verification procedure could look like this: > > The Torproject publishes a central registry of trusted entities that agreed to verify addresses of large scale operators. > > The registry is broken down by area so no central entity needs to see all addresses or is in the position to block all submissions. > (even though the number of physical address verifications are expected be stay bellow 50 for the time being). > > Examples could be: > > Riseup.net: US, ... > Chaos Computer Club (CCC) : DE, ... > DFRI: SE, ... > > (these organizations host Tor directory authorities) > > > - Relay operators that would like to run more than 0.5% guard/exit fraction select their respective area and contact the entity to > initiate verification. > > - before sending an address verification request the operator verifies that they meet the following requirements: > - the oldest relay is not younger than two months (https://community.torproject.org/relay/community-resources/swag/ ) > - all relays have a proper MyFamily configuration > - relays include the verified email address and PGP key fingerprint in the relay's ContactInfo > - at least one of their relays gained the exit or guard flag > - they have a sustained bandwidth usage of at least 100 Mbit/s (accumulated) > - intention to run the capacity for at least 4 months > > - upon receiving a request the above requirements are verified by the verification entity in addition to: > - relay(s) are currently running > - the address is in the entity's area > > - a random string is generated by the address verification entity and send with the welcome tshirt (if requested) to the operator > > - after sending the token the address is deleted > > - upon receiving the random string the operator sends it back via email to the verification entity > while signing the email with the PGP key mentioned in the relays ContactInfo > > - the verification entity compares the received string with the generated and mailed string > > - if the string matches the entity sends the relay fingerprint to the directory authority list to unlock the cap for the operator > > After this one-time procedure the operator can add more relays as long as they are in the same family as the approved relay (no new verification needed). > > > [3] > > exit operators running >=0.5% of exit probability > without exit groups from 2020 > (onionoo data as of 2020-07-03) > > abuse-contact(a)to-surf-and-protect.net 22.73 > Foundation for Applied Privacy 6.05 > John L. Ricketts, PhD <john AT quintex dot com> 5.6 > F3 Netze <abuse(a)f3netze.de> 5.47 > https://www.torservers.net 3.89 > Nicholas Merrill <nick AT calyx dot com> 2.48 > https://www.digitale-gesellschaft.ch/abuse/ 1.74 > Accessnow.org <abuse .AT. accessnow .DOT. org> 1.71 > Hart voor Internetvrijheid 1.63 > <zwiebeln at online de> 1.44 > TNinja <abuse-team at tor dot ninja> 1.43 > tech(a)emeraldonion.org 1.31 > Frenn vun der Enn FVDE 1 > https://www.artikel5ev.de/torcontact/ 0.74 > Nos oignons 0.71 > tor-abuse<at>mailbox<dot>org 0.67 > abuse-node49 AT posteo DOT de 0.57 > tor-operator(a)privateinternetaccess.com 0.52 > > 14 out of these 18 operators have their address already publicly listed because they are registered organizations or similar. > > >

1 0

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale malicious actors
by Tor-Abuse 05 Jul '20

05 Jul '20

Hi nusenu, this sounds quite useful and I would like to support it. I would be fine to do an email and physical address verifiation. Cheers Fabian Am 05.07.20 um 17:54 schrieb nusenu: > nick AT calyx dot com

1 0

Tor is reporting my bridges as offline
by Eddie 02 Jul '20

02 Jul '20

Hi, I run 2 bridges on a hosted VPS. Tor is currently showing both these as offline for the last hour or so, but I can still connect to them from a Tor Browser and looking at the local logs, they are both running quite happily. Any ideas why they are showing as offline: https://metrics.torproject.org/rs.html#search/OhNoAnother Cheers.

3 4

Exit Relay throughput
by torix＠protonmail.com 20 Jun '20

20 Jun '20

Dear List, How important is the throughput on an exit relay? I realize that more is always better, making it harder to associate exit packets with input ones at the other end. My numbers: For the same price I can buy 2 exit relays that run about 3500 to 4000 connections or one that runs about 4300 to 4700 connections. The actual daily throughput varies a good deal, but the cheaper ones show about 15-20% less throughput, at around 330 GiB/day when I look at vnstat. Can I assume 2 is almost always better than one? Or is there a threshold below which packets are too easily tracked? I have no common sense about this. TIA, --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

"/var/tor/diff-cache" full!
by Salvatore Cuzzilla 18 Jun '20

18 Jun '20

Hi Folks, I'm running a non-exit relay (v0.4.2.7) on OpenBSD 6.7. The amount of files within "/var/tor/diff-cache" is steadily increasing. Up to almost 6G fulfilling the /var partition to the max. Is this an expected behavior? I there any solution to overcome it? ------- :wq, Salvatore.

5 5

directory servers working on updates?
by Paul Geurts 16 Jun '20

16 Jun '20

hi, anything up this weekend? [image: image.png] gr. Paul

2 2

ymkeo changing ISP coming Thursday
by René Ladan 14 Jun '20

14 Jun '20

Hi, I'm in the process of switching ISPs and if all goes well this should be complete by coming Thursday. So my relay (ymkeo, 4E8CE6F5651E7342C1E7E5ED031E82078134FB0D) will change its external IPv4 and IPv6 addresses. It is listed as a fallback directory mirror but currently not acting as one, so someone will have to update that list :) New IPv4: 185.238.129.9 /32 New IPv6: 2a10:3781:116:: /48 Regards, René

1 0

Consensus weight/Advertised bandwidth low on "Gigabit" ISP, despite ISP equipment upgrades
by Neel Chauhan 14 Jun '20

14 Jun '20

Hi tor-relays@, I run a FreeBSD-based Tor relay across two instances on "Wave G", a Gigabit ISP in the Seattle metro. You may also know them as CondoInternet or CascadeLink, but I joined only this year on a Wave-branded service. These relays have had low consensus weights since I got the service in January. The instances are below: * https://metrics.torproject.org/rs.html#details/8FABF4D266DF95216F6C646C6D6D… * https://metrics.torproject.org/rs.html#details/CE06BA1EA45FD32A79EAF7FE6A3B… My server and router are fine, I am in the single digits in terms of CPU use on both. The same exact server and router on Verizon FiOS in New York never gave me this issue. There was an underlying ISP performance issue impacting me which led consensus weight values to be low, but my ISP has since upgraded their equipment in my building. In general, my Internet performance has improved by magnitudes. However, my consensus weight has stayed more or less flat since the equipment upgrade, instead of jumping higher. What gives? How long would it usually take for the bandwidth scanners to measure the higher bandwidths? Should I re-key my relays and start from scratch? About switching ISPs, I'm not switching to Comcast for obvious well-documented reasons, and neither CenturyLink nor Frontier/Ziply Fiber serve me, not even copper. Best, Neel Chauhan === https://www.neelc.org/

2 1

IPv6 Port
by Josh Lawson 11 Jun '20

11 Jun '20

I currently have my IPv6 connection running on port 9001. From an anti-surveillance perspective, would I be better changing the port to 80? I have IPv4 running on 443. I appreciate it!

2 3