- tor-relays - lists.torproject.org

Tor Relay Operator Poll (closes on 2023-05-30)
by nusenu 27 May '23

27 May '23

Hi, want to help shape the future of the Tor network? Here is a poll for you: https://cryptpad.fr/form/#/2/form/view/VE-b3bd-IS1P17Povh0ryIHYhqGqEiA7sJMR… It is open until 2023-05-30. Only operators that did run relays/bridges before 2023-04-01 (and are still running) may participate. An AROI or a relay fingerprint (or hashed bridge fingerprint) is required to participate. This poll happens in the context of working on a network health proposal. The goal of this poll is * to gather input from non-malicious relay operators * to help make pragmatical design decisions for an upcoming network health proposal * to ensure it remains practical to implement for relay operators * to get a feeling on whether it has a chance to see actual real world adoption * to get a feeling on whether relay operators would participate in a web of trust * to get a feeling on what type of rules relay operators would find acceptable In the light of malicious entities this poll has been send to large relay operators a few days ago so they can claim their submission first. Their feedback was also used to improve and extend the poll, if you submitted it already once you can submit it again but ensure to submit the same random string at the end as you did the first time so they can be linked. kind regards, nusenu -- https://nusenu.github.io

2 3

ContactInfo semantics
by nusenu 26 May '23

26 May '23

This is probably of interest to many relay operators: https://gitlab.torproject.org/tpo/community/relays/-/issues/71 > Write proposal to restrict contact information field to email address (and make it mandatory) https://gitlab.torproject.org/tpo/core/arti/-/issues/870 > Restrict contact information field in arti to just allow an email address kind regards, nusenu -- https://nusenu.github.io

1 0

Configuring key expiration warning messages?
by telekobold 22 May '23

22 May '23

Hi everyone, I'm using OfflineMasterKey 1 for my Tor bridge, hosting and renewing the long-term identity key on a Tails USB stick. I observed that Tor starts printing warning messages to /var/log/tor/notices.log 24 hours before the intermediate key expires. My question is if there is a flag that could be set in the torrc file to start printing these warning message more than 24 hours before the expiration time, possibly even with outputting the exact expiration time? If there isn't such an option, does anyone happen to have a script ready for this (before I start trying to implement something like this myself)? Kind regards telekobold

3 2

Tor Relay Operator Meetup - April 15th, 2023 at 19 UTC
by gus 22 May '23

22 May '23

Hello, The next Tor Relay Operator Meetup will happen on April 15th, 2023, at 19 UTC. We're still working on the agenda, feel free to add your topics and/or questions on the pad: https://pad.riseup.net/p/tor-relay-op-meetup-april-keep onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… WHERE Room link: https://tor.meet.coop/gus-og0-x74-dzn Registration No need for a registration or anything else, just use the room-link above. We will open the room 10 minutes before so you can test your mic setup. Please share with your friends, social media and other mailing lists! Gus -- The Tor Project Community Team Lead

2 2

mulitply ipv6 bridge lines for a single bridge
by Toralf Förster 21 May '23

21 May '23

Given that hosters of a VPS often gives a big /48, /56 or /64 ipv6 subnet to a VPS I do wonder if the BridgeLine for ipv6 could benefit from that? With ip6tables -t nat -I PREROUTING -p tcp -j DNAT --to-destination [obfs4 address] /usr/sbin/ip6tables-save > /etc/iptables/rules.v6 all incoming TCPv6 packets would be flow to the bridge address. This idea is implemented in [1]. BTW there I do change the factory default ipv6 address into a random one too. [1] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup/tasks/… -- Toralf

1 0

PSA: Tor 0.4.5 reaches end of life (EOL) on 2023-02-15
by Georg Koppen 17 May '23

17 May '23

Hello! In case it affects you as you are still running your relay or bridge on Tor 0.4.5.x: the 0.4.5 series is going EOL on *2023-02-15* (roughly in 3 weeks from now). That's currently still 760 relays, which means roughly 7% of the advertised bandwidth of the network (and 387 bridges, which means roughly 9% of the advertised bridges bandwidth). Please make sure you have upgraded to the 0.4.7.x series by then. Supported releases in general can be found on the network team wiki.[1] Thanks, Georg [1] https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele…

6 8

Re: [tor-relays] MyFamily
by denny.obreham＠a-n-o-n-y-m-e.net 16 May '23

16 May '23

trinity pointard <trinity.pointard(a)gmail.com> wrote .. > . It's not as easy as having a unique ID, you need to make sure a > relay can't spoof being part of a family, that's why it requires a two > way relationship for now, and will probably use some form of signature > in the future. Why not take advantage of the proof entry of ContactInfo? ( https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#pro… ) All you need to do is to add a file like https://example.com/.well-known/tor-relay/family-rsa-fingerprint.txt (uri-rsa) or DNS TXT record family-fingerprint.example.com (dns-rsa) which would contain one of the relay fingerprints of the family (the same one for all relays). The name is thus unique and you can easily check if the family name and corresponding relay fingerprint are linked to the same relay operator. The only drawback is if the chosen relay for the family name is removed from the network then a new one will have to be chosen and all the MyFamily values changed on every relay. Most likely a very rare event. Heck, a file https://example.com/.well-known/tor-relay/rsa-fingerprint.txt has already the same content as MyFamily. (Which I am guessing is one way "Alleged Family Members" are identified on Tor metrics.) _________________ > For an easy example, let's imagine that we let any relay put itself > into any family. Now suppose the attacker starts three relays A1, A2, > and A3. Then, since nothing stops them, they put A1 into a family > with every relay on the network, except for A2 and A3. Now, any time > a user (randomly) selects A1, they will find that the only other > relays they can use on that circuit are A2 and A3; this will build a > completely attacker-controlled path, they will get no privacy. How can you find a family with every relay on the network? According to the proposal, the largest family has 270 members and, according to Tor metrics, they are about 2000 exit relays. Even assuming an attacker controls A1 and A2, both falsely belonging to two different families with 250 members each (assuming all exit relays), the attacker would just increase his chances of having his A3 exit relay to be selected from 1/2000 to 1/1500. Not nothing, but not a large advantage either. The problem you are describing is actually one that is possible RIGHT NOW with MyFamily. An attacker CAN list all relay fingerprints he can find in its MyFamily except his relays. If he could only list ONE family name, he could only spoof it with the most popular family name used (assuming family name uniqueness is not enforced and more than one relay operator use the same name). But it is impossible that all [good] relay operators use the same family name, even if they would be allowed to select one as simple as "Smith". MyFamily with a single name seems both a very tiny spoofing problem AND an improvement over the current configuration.

2 1

MyFamily
by denny.obreham＠a-n-o-n-y-m-e.net 15 May '23

15 May '23

This has probably been addressed before but why isn't the MyFamily value just a single, unique ID? If I have the relays with the fingerprints "John", "Jane", and "Alice" and I want to add "Bob", wouldn't it be simpler (and more logical) to add the unique MyFamily "Smith" to each torrc file than listing all fingerprints? What do you do when you have 50 relays and want to add or remove a relay? You must modify 50 torrc files and restart all 50 relays? That seems tedious and unnecessary. I'm trying to find a way to automate this process and I can wrap my head around the complexity of the problem, especially with multiple servers. I could just use the fingerprint of my first relay as MyFamily (to ensure uniqueness) and then add it to every other torrc file I create in the future. Even if I remove the first relay from the network, the MyFamily value is still valid as a unique "family" name. I don't know the particular procedure, but even the process of blacklisting relays based on MyFamily, when selecting a relay, seems tedious. For example, the entry relay has 50 family members and the middle relay has 50 other family members, so I have to compare the potential exit relay "first" name to 100 "first" names instead of comparing its "family" name to two "family" names. Is this too complicated to implement or am I missing something? Denny

5 4

Open call for proposals for improving the health of the Tor relay operator community and the Tor network
by gus 11 May '23

11 May '23

Hello, We accomplished a number of things in our fight against malicious relays over the last 2 years[1]. One area we still need to focus on is strengthening our relay operator community. We're therefore currently collecting proposals from you or anyone else interested that could help to impove the health of the Tor relay operator community and, thus, provide our users a more trusted Tor network. We're accepting both new and old proposals, and we're open to any ideas you may have. Although there are various proposals for improving the network and the Tor relay operator community, not all of them are being enforced at the moment. Nevertheless, some proposals that can help on increasing trust have been adopted by a meaningful fraction of the Tor community (e.g. providing valid contact information). Another great example of such proposals is the "Expectations for Relay Operators"[2] document, where we guide relay operators to keep the Tor community and the network safe, healthy, and sustainable. We'd love to hear your proposal on how to make it more difficult for attackers to run relays while keeping it easy for good contributors to join our network. You can share your proposals on this GitLab ticket[3] and our tor-relays mailing list. It is worth noting that at the moment we are only trying to map these proposals to get an overview over the various options available. We're not in the process of approving any of them. If you have any experience, positive or negative, with Sybil-resistance and online abuse mitigation projects, we welcome your opinion as well. Since in this debate we have seen previous bad actors trying to game this process and thus lowering the effectiveness of our defenses, the Tor team will take all measures to stop people acting in bad faith and enforce the Tor Code of Conduct and policies. During the Tor Relay Operator Meetup on Saturday (March 4, 2023 - 19UTC), we will be discussing some of these proposals we've collected so far. Thank you, Gus [1] https://blog.torproject.org/malicious-relays-health-tor-network/ [2] https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-R… [3] https://gitlab.torproject.org/tpo/community/relays/-/issues/55 -- The Tor Project Community Team Lead

4 11

Re: [tor-relays] For some reason, my bridge is still saying it has no distribution mechanism, despite it is listed as email in my torrc and says it is overloaded?
by Keifer Bly 23 Apr '23

23 Apr '23

Now its more confusing. That tool says the port is not reachable for both port 8080 and 8081. But the notices.log says the port is reachable. And apparently the accountigmax is being reached..... --Keifer On Wed, Apr 19, 2023 at 8:06 AM meskio <meskio(a)torproject.org> wrote: > Quoting Keifer Bly (2023-04-19 16:46:37) > > How to find that? > > https://community.torproject.org/relay/setup/bridge/post-install/ > > > It gave the message its reachable from the outside. > > This message is saying that the ORPort is reachable from outside, but it > doesn't > test for the obfs4 configured port. You can test it yourself if the port > is > reachable using our reachability test: > https://bridges.torproject.org/scan/ > > Or directly configure the bridgeline in Tor Browser and see if it connects > correctly. > > -- > meskio | https://meskio.net/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > My contact info: https://meskio.net/crypto.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Nos vamos a Croatan.

1 1