- tor-relays - lists.torproject.org

Relay disconnect & offline on IP change
by Tor Relay Net Ops 26 Sep '24

26 Sep '24

Greetings fellow relay operators! I'm currently running a tor relay on a dynamic IP Address connection, usually my ISP gives me a new address every day or so- Lately [for the past like week or so- /can't remember when it started happening/], I have to manually restart it when my WAN IP Address changes; to get the relay back online- (systemctl restart tor@default) Is there a way to not manually restart tor (besides running a cron script to do so) Below are my tor configuration: Tor 0.4.8.12 on Linux Debian GNU/Linux 12 (bookworm) /etc/tor/torrc Nickname hadleyJamison ContactInfo url:darrenofficial.com proof:dns-rsa ciissversion:2mailto:tor-relay-netops@darrenofficial.com ORPort 88 IPv4Only ExitRelay 0 SocksPort 0 ControlPort 9051 CookieAuthentication 1 RelayBandwidthRate 69 MBits RelayBandwidthBurst 69 MBits -darren

6 6

Dear OBFS4 bridge operators, please enable timing and packet-size obfuscations to help clients facing timing analysis attacks.
by George Hartley 25 Sep '24

25 Sep '24

Hello Tor community, this e-mail applies to you if you are running an obfs4 (now known under the name lyrebird) bridge or want to do so in the future. Some recent posts on this list has shown that traffic timing analysis can be used to locate a users or onion services guard nodes or bridges. This is not really something new. For bridge users, there is a way to try to protect themselves against this, but your bridge configuration must support it. By enabling iat-mode on your obfs4 /lyrebird bridge, then maybe DPI (Deep Packet Inspection) hardware can sometimes be defeated either entirely, or at least the process of tracking users can be slowed down. OBFS4/Lyrebird support two times of traffic obfuscation: > ServerTransportOptions obfs4 iat-mode=1 This will make your bridge send MTU sized packets, in order to make true packet size analysis harder. There is also what the author of obfs4/Lyrebird called "paranoid mode": > ServerTransportOptions obfs4 iat-mode=2 For each write, a variable length packet will be sent, which will result in both making true packet size and round trip time analysis harder. If your bridge is distributed by BridgeDB, the next time someone receives a batch of bridges with your bridge in it, the bridge-line will have the iat-mode variable set to the one you set on your bridge server. Your bridge will still work even if you enable these defenses and a user chooses to set iat-mode to 0 in his bridge line. There is a small performance penalty for both mode 1 and 2, but nothing very severe. I believe this, along with Vanguards, and so on, is needed to keep users and services somewhat secure. Let me know what you think. - George

5 8

Looking for a ipv4 block and strategy
by Osservatorio Nessuno 24 Sep '24

24 Sep '24

Hi everyone, our organization is working to add more physical nodes, in our little Italy headquarter[1]. We have reached an agreement with one of the available fiber reseller there, where we will pay for L2 transport to a datacenter, where we will buy our uplink separately and announce and route our public IP addresses independently. It is actually a very nice opportunity to remove a point of trust in the chain and get back control to a part of infrastructure that is usually delegated to commercial ISP. Similarly, as this list knows well, by announcing our IPs we will be the direct recipients of any abuse. We have now two options: either look for someone willing to lease a /24 to Tor operators, which is not an easy task since the block reputation will be tainted and depreciate the block. We have found someone willing to, for $119/mo, but it is hard to tell how long that will last. An alternative would be to buy it, for around ~7k$ (~28-31$ per IP, via a broker). We do not have the budget for this now, but an organization member has offered to lease the money and get paid back without interest at a similar rate that a lease would cost (around $1k year). In all phases, the block will be in the org ownership. We have someone who can LIR sponsor at RIPE so we would not have other recurring expenses. Buying is more sustainable in the long-term: in around 6 years we will stop to have to pay the lease. At the same time, we will not have any chances to change those IP ever later, while in a lease, we could eventually move to other blocks. Does anybody in the community have contacts for lease or sale? Is there any foreseeable issue in sticking to the same range for the next ~10 years? Especially at the beginning, it will be unlikely that we will use even 1/4 of them, but given how the fiber infrastructure is built, we can eventually use the same announcements even for other physical locations. Thank you [1] - https://osservatorionessuno.org/blog/2024/07/we-have-a-headquarter-and-it-i…

2 2

Why I do have so often an "8" in my bridge stats?
by Toralf Förster 24 Sep '24

24 Sep '24

Never cared about this before, but isn't the "8" too often here? : $ cat ~/tmp/tor_bridge_stats i10 bridge-ips ru=264,br=16,de=16,us=16,au=8,cl=8,co=8,cz=8,dz=8,eg=8,es=8,fr=8,gb=8,gr=8,hk=8,id=8,in=8,ir=8,it=8,kr=8,lt=8,lv=8,nl=8,ph=8,sa=8,sg=8,tw=8,ua=8,ve=8 i11 bridge-ips ru=152,ir=16,cn=8,cz=8,de=8,gb=8,nl=8,pl=8,tr=8 i12 bridge-ips ru=224,by=8,cn=8,de=8,fr=8,in=8,ir=8,jp=8,nl=8,pl=8,ro=8,us=8 i13 bridge-ips de=8 i14 bridge-ips de=8,fr=8,ru=8 i15 bridge-ips de=8,ru=8 i20 bridge-ips de=8 i21 bridge-ips de=8 i22 bridge-ips ru=96,at=8,de=8,nl=8,pl=8,us=8 i23 bridge-ips ru=904,ir=48,eg=32,de=24,us=24,fr=16,ae=8,at=8,be=8,br=8,by=8,ca=8,co=8,cz=8,dz=8,fi=8,gb=8,gr=8,hk=8,hu=8,im=8,in=8,it=8,jp=8,kz=8,lv=8,ma=8,md=8,mm=8,na=8,ni=8,nl=8,pk=8,pl=8,sa=8,se=8,tm=8,tr=8,tz=8,uz=8,ve=8,ye=8,za=8 i24 bridge-ips de=8 i25 bridge-ips ru=112,ch=8,cn=8,de=8,gh=8,in=8,ir=8,ke=8,mm=8,mu=8,nl=8,tr=8,us=8 i26 bridge-ips de=8 luchs bridge-ips de=8 -- Toralf

2 3

Read/written bytes on a relay differ
by Richie 23 Sep '24

23 Sep '24

Hi everyone, nothing of real concern, but out of curiosity: since some years now i use overhead traffic on my ISP for Tor, with a small home relay burning some 3 to 4 MB/Sec. Usual middle relay plus V2Dir (and HSdir some days after last reboot). Since some weeks now, the read/written bytes differ quite significantly, and i never experieced sth like that for a relevant timespan before. Is this a sign of more "reading directory services" on the relay? (maybe short reqests and verbose replys), some new kind of attack, whatever? direct metrics-Link via https://metrics.torproject.org/rs.html#details/11FC7D9C7D8DF74326B90EC71C10… and screenie attached. Again, no big issue, just curiosity. And if its some kind of bug, i'd be happy to hand over more info. thx to everyone maintaining and running this stuff, Richie

2 1

[Important] Update on an upcoming German broadcasting story about Tor/Onion Services
by isabela fernandes 19 Sep '24

19 Sep '24

Hi Tor, I am reaching out to inform you of an upcoming news story concerning a potential deanonymization attack on Onion Services. What is happening? On September 9, 2024, The Tor Project received a press inquiry from Norddeutscher Rundfunk (NDR, part of ARD, a German public broadcaster) with a request for comment to their upcoming reporting of "investigative measures by German and international law enforcement agencies in the Tor network, in particular the localisation and deanonymisation of onion services." We complied with the outlet's deadline of September 12th and answered a series of questions. The reporter claims to have "evidence that shows that in several cases German law enforcement authorities were able to locate the Tor entry node of onion services and thus successfully deanonymise Tor users. V2 and V3 onion addresses were affected at least between Q3/2019 and Q2/2021." The reporter further claims that "law enforcement agencies used so-called timing analyses and broad and long-term monitoring of Tor nodes in data centres." As of today, The Tor Project has not been granted access to supporting documents, and has not been able to independently verify if this claim is true, if the attack took place, how it was carried out, and who was involved. In the absence of facts, it is hard for us to issue any official guidance or responsible disclosures to the Tor community, relay operators, and users at this time. We are calling for more information from you. If you have any information that can help us learn more about this alleged attack, please email security(a)torproject.org. If you want to encrypt your mail, you can get the OpenPGP public key for this address from keys.openpgp.org. Fingerprint: 835B 4E04 F6F7 4211 04C4 751A 3EF9 EF99 6604 DE41 Your assistance will help all of us take the necessary steps and precautions to keep Onion Services safe for the millions of users that rely on the protections Tor provides. Are Tor users safe? Tor users can continue to use Tor Browser to access the web securely and anonymously. Nothing that the Tor Project has learned about this incident suggests that Tor Browser was attacked or exploited. We encourage Tor Browser users and relay operators to keep software versions up to date. The reporter's questions focus on the use of onion services and .onion addresses. Which leads us to assume that the alleged attack was targeting a specific .onion site. We will continue to share updates on this email as this situation evolves. Thank you! Isabela

9 10

[warn] Error relaying cell across rendezvous; closing circuits
by Logforme 16 Sep '24

16 Sep '24

I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 Today I noticed two [warn] lines in the Tor log file that I have not seen before: [warn] Error relaying cell across rendezvous; closing circuits [warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/core/or/command.c:577 (first at ../src/core/or/relay.c:343) (on Tor 0.4.8.12 ) I assume this is more of a FYI for the developers than for me as an operator. I'll keep an eye out to see if they appear more times.

1 0

Re: [tor-relays] tor-relays Digest, Vol 164, Issue 10
by Account Etheron 14 Sep '24

14 Sep '24

Your node has low Consensus Weight. Also your node is not marked as "Fast" Normal that happens between a week. Also advertised traffic is very low. https://metrics.torproject.org/rs.html#details/A00E3AAF5A24DC69740FA7A3A1C4… Low Consensus Weight (like 11) could be due to several factors: 1. *Low Bandwidth*: If your node has a limited bandwidth or is not properly configured to advertise its available bandwidth, it might get a lower weight. 2. *Unstable or Intermittent Availability*: Nodes that are frequently going offline or showing unstable behavior will have a lower consensus weight. 3. *Geolocation or Restrictions*: Certain regions or configurations may cause your node to have reduced visibility or reliability in the eyes of Tor's directory authorities. To improve the consensus weight of a Tor node: - Ensure *high uptime* and a reliable internet connection. - Advertise higher *bandwidth* if available. - Make sure your node is properly configured with the *right ports and keys*. Regards. On Sat, Sep 14, 2024 at 2:00 PM <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Relay suddenly pushing very little traffic (Zachary) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 13 Sep 2024 12:23:52 +0000 > From: Zachary <secure-communications-zachary(a)protonmail.ch> > To: "tor-relays(a)lists.torproject.org" > <tor-relays(a)lists.torproject.org> > Subject: [tor-relays] Relay suddenly pushing very little traffic > Message-ID: > > <jOspt2hq9xeYGyZ8fsFy_qO_4d_TtxrOmCJxPIPzAyF948JHR0_2saC8hGGKPkleMwcLMFcXbPVucHhRfnXLZfBjn_Wx2VYGC46r1wpqnaI=@ > protonmail.ch> > > Content-Type: text/plain; charset="utf-8" > > 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

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