- tor-relays - lists.torproject.org

Tor People @ WHY2025
by Alexander Hansen Færøy 11 Aug '25

11 Aug '25

Hey Relay Operators, I'll be at the upcoming WHY2025 hacker camp in the Netherlands. WHY2025 is an excellent opportunity to do a Relay Operator meetup at some point during the camp days. Who else from here is going? At the latest CCCamp, we did a meetup at the BornHack village, but we did receive some negative feedback on the noise level in that general area, so I was thinking of investigating if there is a quieter place with some good seating where we could host the meetup this time, and announce the time and location here on the list. Suggestions of locations are most welcome. I recently received a link from tornth on #tor-relays on IRC/Matrix to https://wiki.why2025.org/Project:Tor_Relays, where it's relatively easy to add "Tor Relays" as a project from your WHY2025 wiki account. Cheers, Alex -- Alexander Hansen Færøy

4 6

Low consensus weight votes from European authorities
by Skye Clayton 11 Aug '25

11 Aug '25

Hello, I’ve had a non-exit relay (602D56DFD408530F7FE3056CAF1DA413A50ECAE4) that has been getting low weight votes from authorities like tor26, gabelmoo, and maatuska, compared to other authorities like moria1 and bastet after checking with the consensus-health tor site. At first, I questioned my ISP (ATT Fiber)’s routing to Germany based on an authority IP so I speedtested to four speedtest.net servers in Nuremberg but I received expected bw and around 100ms ping. Regardless, my relay hasn’t had anywhere as much traffic as it should have, and my relay is essentially offering resources to the Tor network that are being devalued right now. My relay’s consensus weight is around 3000, even though moria1 and bastet vote mine around 10000. I would also ask for the Tor developers’ reasoning for using median of authorities in consensus weighting rather than mean since in my mind, if no authorities are malicious/compromised to give false values, then mean would give a more accurate representation of actual measured bw performance from the authorities, IMO. Is median only used because of a large prevalence of extremely skewed bw vote distributions? Can this be remedied in software to allow for mean usage later on? Any help would be appreciated :)

2 1

FW: Re: Tor
by C. Pe. 11 Aug '25

11 Aug '25

forgot to copy the list. ---------------------------------------- Betreff: FW: Re: [tor-relays] Tor Von: C. Pe. <peca-relay(a)mailfence.com> An: CIP <ciptorrelays(a)gmail.com> Datum: 09.08.2025, 17:10:51 Hi, after looking at the first five entries from your list, I observe one common pattern: - Each relay has got a reachable IPv6 address (next to IPv4) - Each relay has an IPv4 exit policy - Each relay has got NO IPv6 exit policy (i.e. "reject 1-65535") Could that be the reason? You have, so to say, an IPv4-exit and at the same time an IPv6 middle-only-relay. (Please note, that I am NOT a member of torproject.org, but just a bridge and non-exit relay operator, so I do not have any further insight) Regards, C. Am 08.08.2025 um 05:13, CIP via tor-relays <tor-relays(a)lists.torproject.org> schrieb: Hello. We launched 20 Tor relays about a few weeks ago. We have learned that all of our relays have 2 strange flags: BadExit and MiddleOnly. Why are these flags assigned to our relays? Did we misconfigure something? Here is a list of our relays: E977DB4A822E3A949E6C2819AEBC3414CE214CF1 CBBAE95A4EE11633C435F7080BC6A03683045E09 06D96F28744B5E904E29A0E5B30EF6939200A657 999CA95B7F7ED9084360F8DA45CBD128FE677450 B6B64E54F1480F649F15E54DDC13E0CEE24117A1 4B55ED89F4DCF003EFEA1F899F6242D484A201CB C3E1511072DA6EFCF14232DB12D7E0B41B493A05 8E57FA4CCCCCA55D5E0DBCA6EEB63D7893CCAC9C 00A591A34E271E1A2BE595B03FA1F349E113589A BA20A8077D27CFE1701805920754867152C23863 4F1557DF7CD3E92880638BB72A0FCC5A30750794 66CE6400C5868EF548FB992D375D7CC8D61ABA4C DF70D38C775156A4662BC9BD9B2565D83663626B F2D902F0E8C40BE0E4328BA825DEAF7A72F0CCE7 C9BB71EA60EB1E5BBE6437E9F95426910E921940 E91A14923166F88221EF6AB9070C1C6702C3B293 81B242FE18D95A39535AFECEDADEBA8969C3FD3A C32A47FD85627A0D4F6EE121C9FA976D77F90160 3E7C2C3065EBAB57C9C1200BE26922F81DE67F16 AC80958B66FE21FAF5B6105F631BC4A7744F64EC _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email -- Sent with https://mailfence.com Secure and private email

3 3

No update of bridge distribution method?
by C. Pe. 09 Aug '25

09 Aug '25

Hello all, next to my posts about the NAT and non-default IP for bridges topic, I would like to draw your attention to my observation, that somehow, bridge distribution seems not updating and hence no distribution and no traffic. Please refer to the below examples, which all are configured properly without any "special" situation: E80088962F97FE190D734D67E0C656C2A6EADEE7 (webtunnel, on distribution method "none" since more than a week, despite method manually set in torrc) 45E1449B8B87ACFE6AF40CD33E91DFC3CB9B7488 (obfs4, this one is active way longer than indicated in "first seen", also shown as distribution "none") Is something wrong with the distribution DB ? Thanks & regards, C. -- Sent with https://mailfence.com Secure and private email

1 0

Tor
by CIP 09 Aug '25

09 Aug '25

Hello. We launched 20 Tor relays about a few weeks ago. We have learned that all of our relays have 2 strange flags: BadExit and MiddleOnly. Why are these flags assigned to our relays? Did we misconfigure something? Here is a list of our relays: E977DB4A822E3A949E6C2819AEBC3414CE214CF1 CBBAE95A4EE11633C435F7080BC6A03683045E09 06D96F28744B5E904E29A0E5B30EF6939200A657 999CA95B7F7ED9084360F8DA45CBD128FE677450 B6B64E54F1480F649F15E54DDC13E0CEE24117A1 4B55ED89F4DCF003EFEA1F899F6242D484A201CB C3E1511072DA6EFCF14232DB12D7E0B41B493A05 8E57FA4CCCCCA55D5E0DBCA6EEB63D7893CCAC9C 00A591A34E271E1A2BE595B03FA1F349E113589A BA20A8077D27CFE1701805920754867152C23863 4F1557DF7CD3E92880638BB72A0FCC5A30750794 66CE6400C5868EF548FB992D375D7CC8D61ABA4C DF70D38C775156A4662BC9BD9B2565D83663626B F2D902F0E8C40BE0E4328BA825DEAF7A72F0CCE7 C9BB71EA60EB1E5BBE6437E9F95426910E921940 E91A14923166F88221EF6AB9070C1C6702C3B293 81B242FE18D95A39535AFECEDADEBA8969C3FD3A C32A47FD85627A0D4F6EE121C9FA976D77F90160 3E7C2C3065EBAB57C9C1200BE26922F81DE67F16 AC80958B66FE21FAF5B6105F631BC4A7744F64EC

3 2

QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 07 Aug '25

07 Aug '25

Dear experts, I have a special question, for which I could not find 100% clear documentation after a research. Situation: - VPS with more than one IPv4 and IPv6 address - IPv4 within the VPS is private class-A only (i.e. 10.x address), so port binding happens to the private Class-A - External IPv4 is linked outside the VPS to the private Class-A - of course, VPS is externally reachable by the external IPv4 - I would like to use a secondary IPv4, i.e. NOT the one, which is shown, when you run the command 'curl -4 icanhazip.com' from within the VPS) - I would like to use a secondary IPv6, i.e. NOT the one, which is shown, when you run the command 'curl -6 icanhazip.com' from within the VPS) Let's assume, for my example only, I have the following secondary IP addresses : - external IPv4 7.8.9.10 - internal IPv4 10.0.0.7 - IPv6 [2345:bad:face::] Let's further assume, my ORPort was 1234 and the obfs4 port was 4321 In order to have TOR distribute the correct bridge line "obfs4 7.8.9.10:4321 <...>", is the following torrc config correct? BridgeRelay 1 ORPort 7.8.9.10:1234 NoListen ORPort 10.0.0.7:1234 NoAdvertise ORPort [2345:bad:face::]:1234 Address 7.8.9.10 Address [2345:bad:face::] OutboundBindAddress 10.0.0.7 OutboundBindAddress [2345:bad:face::] ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 10.0.0.7:4321 ExtORPort auto ContactInfo johndoe(a)nowhere.org Nickname MyCoolBridge With this config, I indeed am able to connect to the bridge using the "obfs4 7.8.9.10:4321 <...>" bridge line, but is this line also communicated like that by the bridge distributor, or do I need to adapt the above config to ensure proper distribution? Thanks & regards, C. -- Sent with https://mailfence.com Secure and private email

5 10

FW: RE: Re: Re: QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 05 Aug '25

05 Aug '25

Seems I only answered to George, instead of all, sorry. ---------------------------------------- Betreff: FW: RE: Re: [tor-relays] Re: QUESTION: OBFS4 on secondary IP and NAT Von: C. Pe. <peca-relay(a)mailfence.com> An: George Hartley <hartley_george(a)proton.me> Datum: 05.08.2025, 14:41:41 I am of course not the expert here. However - NoAdvertise and NoListen are usually combined in two consecutive ORPort statements. This is done to in fact to tell Tor to "listen to ip:port A, but advertise ip:port B", so there definitely is an advertisement of the relay. A relay works fine with that and the "relay piece of a bridge" (so to say) also works well. But yes, there indeed IS some hassle with the bridge distribution (see also my other post, which still waits moderator approval). Question remains: Is that a known "shortcoming" for pluggable transports, or is there a special way needed to configure this properly? So we seem to have two issues with bridge setup, NAT and binding to specific IP: 1. Not possible to properly advertise/distribute obfs4 external IP, if obfs4 port binding to internal IP. 2. In such cases, bridge distribution does not happen. I have, based an observation from another bridge without NAT, even the impression, that specifying a specific IP instead of 0.0.0.0 or [::] in the ServerTransportListenAddr causes a bridge distribution "none". Maybe a bug? C. On August 5, 2025 at 4:46 AM, George Hartley <hartley_george(a)proton.me> wrote: Is this not the purpose of NoAdvertise? You use that flag if you want a private bridge (for example, to give to your friends). Using both NoAdvertise and NoListen on an OBFS4 bridge behind NAT can make BridgeDB treat your bridge as “no distribution.” Because NoAdvertise strips the bridge descriptor from publication, and NoListen prevents the ORPort from binding on your public interface, BridgeDB can’t see or test your bridge. As a result, it marks its distribution status as “None.” The easiest fix is to forward your ORPort through NAT and remove (or at least temporarily disable) those flags so your bridge descriptor is published and reachable. Once BridgeDB can reach and verify your ORPort, it will resume distributing your bridge normally. If you’d like more control, you can also set a specific BridgeDistribution method (for example, moat) in your torrc. Regards George On Tuesday, August 5th, 2025 at 3:46 AM, Gary C. New via tor-relays <tor-relays(a)lists.torproject.org> wrote: I'm seeing a similar issue with a recently configured OBFS4 bridge using NAT, NoAdvertise, NoListen, and distribution status displaying as "None." On Sunday, August 3, 2025 at 12:36:37 PM MDT, C. Pe. via tor-relays <tor-relays(a)lists.torproject.org> wrote: Is there maybe another issue with rdsys being "stuck" ? I have again a new/renewed bridge in distribution status "None" since some days and https://bridges.torproject.org/status?id=<fingerprint> shows for all bridges the last testing two days ago (According to your below statement, updates should appear latest after 4h) Thanks & regards, C. Am 31.07.2025 um 13:12, meskio via tor-relays <tor-relays(a)lists.torproject.org> schrieb: You can always check if the bridgeline distributed by rdsys is correct by visiting: https://bridges.torproject.org/status?id=<your hashed or not fingerprint> This should display one bullet point per IP/transport, so in your case two, one for IPv6 and another for IPv4. Take into account that it might take up to 4h for this page to be updated when you do changes. -- Sent with https://mailfence.com Secure and private email _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email -- Sent with https://mailfence.com Secure and private email

2 1

Usefulness of independent Snowflake network?
by Jonah Aragon 27 Jul '25

27 Jul '25

Hi all, I’ve spent some time setting up a standalone Snowflake network this week, mainly for my own practice. Basically what I have is: - A Snowflake broker working with domain fronting on a CDN other than CDN77, and of course Amp Cache. - Two Snowflake bridges, https://metrics.torproject.org/rs.html#search/Triplebit%20transport:snowfla… - A handful of proxies with high-speed/no-NAT connections configured to use this network instead of the default. And everything works perfectly in stable Tor Browser. I was mostly curious about what the performance would look like, and of course it is better since I’m the only one using it :) I was thinking that a potential use could be to have a Snowflake network that has no browser extension proxies or proxies behind NAT, only standalone daemons on high-performance networks from operators willing to contribute. My theory is that there are some people who would benefit from a Snowflake bridge with performance more in line with obfs4 or WebTunnel, which may or may not really be true. What I’m wondering is, do you think this is a concept worth pursuing, or do I just leave it as a weekend experiment? Obviously a big advantage is lost by having fewer proxies compared to the current Snowflake network, which would make it easier to enumerate. I think a big advantage gained as a bridge operator is being able to publish the bridge line publicly and take advantage of domain fronting without actually proxying Tor traffic through a CDN. I can change the IPs of my bridges by swapping out proxies, without bridge users needing to update their bridges in their client, which seems like a win. What I don’t know: - Could this actually provide the same or greater value than just contributing more standalone Snowflake proxies to the public network? - Is this worthwhile compared to simply running WebTunnel bridges? - Is there one other relay association perhaps willing to volunteer to run a bridge on this network, and are there other relay associations or individuals willing and able to contribute only high-performing and standalone proxies to it? Let me know what you think! Best, Jonah

1 0

Re: webtunnel bridges for the telegram distributor
by George Hartley 24 Jul '25

24 Jul '25

Thanks, I agree that obfs4 looks like "random data" so it is relatively easy to block with middle-boxes or deep packet inspection. George On Monday, July 21st, 2025 at 1:19 PM, meskio <meskio(a)torproject.org> wrote: > Quoting George Hartley (2025-07-18 05:32:28) > > > > Russia is extending their Tor block[0]. Currently, they block Fully > > > Encrypted >Protocols like obfs4 on some mobile networks[1]. > > > > Does this also apply to obfs4 bridges with timing and packet-size obfuscation > > enabled on both client and server side (iat-mode=2)? > > > Yes, is not that they are detecting obfs4 as a protocol, but they block anything > that looks like random and they can't recognize. > > > -- > meskio | https://meskio.net/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > My contact info: https://meskio.net/crypto.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Nos vamos a Croatan.

1 0

facing out the moat bridge distributor
by meskio 23 Jul '25

23 Jul '25

tl;rd: if you have a bridge configured with "BridgeDistribution moat" remove this config option from torrc so it can be reassigned to another distributor or replace "moat" by "settings". In December we shutted down bridgedb[0] and stopped distributing "moat" bridges. The distributor that the Tor Browser uses automatically "settings"[1]. We hold the existing moat bridges without being distributed as they were still used by people around the world. So censors can't find them and users can still use them without getting blocked. As the usage of those bridges has declined now we decided to redistribute those bridges and automatically assign them either to the "settings" or "telegram"[2]. The only bridges that are not automatically reassigned are the ones with a configuration "BridgeDistribution moat". rdsys will not assign to any distributor bridges that have "BridgeDistribution" assigned to an unexisting distributor. If you run such bridge please remove the BridgeDistribution config line in torrc or change it an existing distributor so your bridge get distributed. If you want to hold your bridge undistributed is better to configure it with "BridgeDistribution none". Thank you. [0] https://blog.torproject.org/making-connections-from-bridgedb-to-rdsys/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/dis… [2] 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.

1 0