September 2024 - tor-relays - lists.torproject.org

turning off BridgeDB and the future of moat bridges
by meskio 03 Oct '24

03 Oct '24

Hello, tl;rd: moat bridges are not distributed anymore. Don't shut them down as they are still used but don't create new bridges with "BridgeDistribution moat". BridgeDB has being our bridge distribution system since 2007. For years we have being developed a replacement of BridgeDB[0] called rdsys[1]. And finally yesterday we replaced the last distributors missing in rdsys (email, https and moat) and turned off BridgeDB. The only visible difference is that captchas has disappeared from https://bridges.torproject.org and requesting bridges in Tor Browser gives you a static captcha and doesn't even verify if the answer is correct (until we have the time to update TB to don't request the captcha[2]. The mayor difference for bridge operators is that we don't distribute "moat" bridges anymore. We have merged circumvention settings and moat and now is one distributor handing over "settings" bridges. For now we are going to keep the existing "moat" bridges assigned to "moat" and don't distribute them, so users that have one of those bridges can keep using them without risk of censors finding it. New bridges will not be assigned automatically the moat distributor, only existing bridges or bridges with "BridgeDistribution moat" will stay in this distributor. We plan to watch the usage of moat bridges and evaluate moving them to another distributor depending on the usage[3]. Thank you for running bridges. [0] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/ [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42086 [3] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/233 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

3 6

Docker Snowflake Proxy Multiple IPs
by admin＠likogan.dev 02 Oct '24

02 Oct '24

Hello, I'm writing because I want to run a snowflake proxy in a docker container on a server with two IP addresses; the primary public IP I want the snowflake proxy hosted on, and a public anycast IP that's shared between other servers. I'm concerned the snowflake proxy may try listening on the anycast IP, which will cause problems as this IP is shared between a few servers! >From my understanding, a snowflake proxy should use the "host" network option with docker. How can I specify which IP address to use with this option? Thanks, Likogan

2 1

relays and CUPS vulnerabilities
by George 30 Sep '24

30 Sep '24

There are some very significant recent CVEs out for CUPS, the unix printing system. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cups It's an ideal moment to remind relay operators that a Tor node, relay or bridge, should be a single-purpose internet server. Running alternate internet services is a bad idea. The node should have the minimum packages installed for the purpose of running a node. More packages means more possible vulnerabilities. Needless to say, a CUPS server listening on 631/tcp or 631/udp while providing Tor access is a bad idea. g -- 43C2 85B0 41B6 4AC1 0E02 2767 7092 AEB3 40B0 C804

3 3

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