- tor-relays - lists.torproject.org

Tor: Possible bug on 0.4.8.9 exit relay.
by George Hartley 18 Dec '23

18 Dec '23

Hi, while going through journalctl I noticed the following entries from my exit relay and wanted to report this non-fatal assertion. I also host a Guard relay on the same VM and IP, and it did not yet assert that message. The full assert() with the stack-trace is as follows: > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] tor_bug_occurred_(): Bug: src/core/or/conflux.c:565: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.9 )Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: Tor 0.4.8.9: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at src/core/or/conflux.c:565. Stack trace: (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x5d) [0x5fdf47b6a9ad] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x194) [0x5fdf47b81764] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(conflux_decide_next_circ+0x3fe) [0x5fdf47c2031e] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(circuit_get_package_window+0x6d) [0x5fdf47c285ed] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x9bc59) [0x5fdf47b15c59] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xa9) [0x5fdf47b15e39] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(connection_edge_process_inbuf+0x76) [0x5fdf47c42866] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x1c0218) [0x5fdf47c3a218] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x6e72d) [0x5fdf47ae872d] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(+0x22c45) [0x7d444a49cc45] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x7d444a49e3af] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x104) [0x5fdf47ae8f44] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x215) [0x5fdf47aed165] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_main+0x5e) [0x5fdf47aed5ee] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(main+0x1d) [0x5fdf47adf08d] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libc.so.6(+0x27cd0) [0x7d4449a7ecd0] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7d4449a7ed8a] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(_start+0x25) [0x5fdf47adf0e5] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x5fdf581d3460 idx 4524 marked at line src/core/or/command.c:663 (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] tor_bug_occurred_(): Bug: src/core/or/conflux.c:565: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: Tor 0.4.8.9: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at src/core/or/conflux.c:565. Stack trace: (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x5d) [0x5fdf47b6a9ad] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x194) [0x5fdf47b81764] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(conflux_decide_next_circ+0x3fe) [0x5fdf47c2031e] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(circuit_get_package_window+0x6d) [0x5fdf47c285ed] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x9bc59) [0x5fdf47b15c59] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xa9) [0x5fdf47b15e39] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(connection_edge_process_inbuf+0x76) [0x5fdf47c42866] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x1c078f) [0x5fdf47c3a78f] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x6e72d) [0x5fdf47ae872d] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(+0x22c45) [0x7d444a49cc45] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x7d444a49e3af] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x104) [0x5fdf47ae8f44] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x215) [0x5fdf47aed165] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_main+0x5e) [0x5fdf47aed5ee] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(main+0x1d) [0x5fdf47adf08d] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libc.so.6(+0x27cd0) [0x7d4449a7ecd0] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7d4449a7ed8a] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(_start+0x25) [0x5fdf47adf0e5] (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.9 ) > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x5fdf581d3460 idx 4524 marked at line src/core/or/command.c:663 (on Tor 0.4.8.9 ) Note how it happened twice for the same circuit. This is the relays configuration: > # Main Config > User tor > ORPort 443 IPv4Only > DirPort 0 > SOCKSPort 0 > ControlPort 9051 > ShutdownWaitLength 60 > CookieAuthentication 1 > Nickname TrafficGuardExit > RelayBandwidthRate 12500 KBytes > RelayBandwidthBurst 15000 KBytes > DataDirectory /var/lib/tor/tor_exit > ContactInfo 0x576768BA hartley_george(a)proton.me > > # Exit Policy > > ExitPolicy reject *:22 > ExitPolicy reject *:25 > ExitPolicy accept *:* > > # Node Family > > MyFamily $AF42E6C77196A37F041A1A1E953E51B4656BDC1B, $7F7D1A5BE88FA7C9358955705AE7AFA61EEDA2B0 > > # Acceleration > > HardwareAccel 1 > NumCPUs 4 > > # Sandboxing > > Sandbox 1 I will try to cooperate as best as possible, but my life is kind of messy right now. And because of TROVE-2023-007, I will have to update the relay to version 0.4.8.10, and reading the change-log of that version, it might actually fix this assert. Still wanted to let you guys know.

2 1

Issue with Relay Status Discrepancy on Tor Metrics
by Jan 18 Dec '23

18 Dec '23

Dear Tor Metrics Support Team, I hope this message finds you well. I am writing to report an issue regarding the status of my relay on Tor Metrics. According to Nyx, my relay appears to be running without any problems. However, Tor Metrics indicates that it is offline. Relay Details: Name:BtcToTheMoon IP Address: 116.203.227.107 Contact Email: janthor007(a)gmail.com I have verified through Nyx that the relay is operational, yet the status on Tor Metrics remains unchanged. I am concerned about this discrepancy and would appreciate any assistance in resolving this matter. Thank you for your attention to this issue. Your help in rectifying this discrepancy would be greatly appreciated. Sincerely, Michal

2 1

Running a high-performance pluggable transports Tor bridge (FOCI 2023 short paper)
by David Fifield 11 Dec '23

11 Dec '23

Linus Nordberg and I wrote a short paper that was presented at FOCI 2023. The topic is how to use all the available CPU capacity of a server running a Tor relay. This is how the Snowflake bridges are set up. It might also be useful for anyone running a relay that is bottleneck on the CPU. If you have ever run multiple relays on one IP address for better scaling (if you are one of the relay operators affected by the recent AuthDirMaxServersPerAddr change), you might want to experiment with this setup. The difference is that all the instances of Tor have the same relay fingerprint, so they operate like one big relay instead of many small relays. https://www.bamsoftware.com/papers/pt-bridge-hiperf/ > The pluggable transports model in Tor separates the concerns of > anonymity and circumvention by running circumvention code in a > separate process, which exchanges information with the main Tor > process over local interprocess communication. This model leads to > problems with scaling, especially for transports, like meek and > Snowflake, whose blocking resistance does not rely on there being > numerous, independently administered bridges, but which rather forward > all traffic to one or a few centralized bridges. We identify what > bottlenecks arise as a bridge scales from 500 to 10,000 simultaneous > users, and then from 10,000 to 50,000, and show ways of overcoming > them, based on our experience running a Snowflake bridge. The key idea > is running multiple Tor processes in parallel on the bridge host, with > externally synchronized identity keys.

3 4

obfs4 bridge management
by Christopher Sheats 10 Dec '23

10 Dec '23

Hello, I've has published a shell script for deploying and managing obfs4 bridges, I hope its useful to others. https://github.com/emeraldonion/bridge-management/ Feedback welcome! -- yawnbox https://disobey.net/@yawnbox https://digitalcourage.social/@EmeraldOnion

1 0

Exit operators on the 0.4.8.x series, please upgrade to 0.4.8.10 ASAP!
by Georg Koppen 10 Dec '23

10 Dec '23

Hello exit node operators! Today (2023-12-08) the Network Team has released a new Tor version, 0.4.8.10[1]. This update contains a fix to a remotely triggerable crash bug (TROVE-2023-007) affecting exit relays on the 0.4.8.x series. Please upgrade as soon as possible to maintain network stability and security if your relays are on that series. For those of you running their Tor relays using the Tor Debian repository, expect a new deb package to be available soon. Please note that this bug is specific to Tor exit relays on the 0.4.8.x series and does not impact other relays nor Tor clients or Tor powered apps (Tor Browser, Orbot, OnionShare). Thanks, Georg [1] https://forum.torproject.org/t/security-release-0-4-8-10/10536

3 2

Relay question
by Mulloch94 08 Dec '23

08 Dec '23

Greetings, I was directed to this relay subscription by the owner. I've recently started my own relay and everything has went smooth for the first few days. Then the relay mysteriously went offline for a period of 8-9 hours. Happened while I was sleeping I think, but any rate it came back on after I restarted the tor daemon and rebooted the server. I'm starting to think my firewall configurations might have been the culprit, even though I ran a very rudimentary setup. Basically just: -A INPUT -p tcp --dport <my SSH> -j ACCEPT -A INPUT -p tcp --dport 9050 -j ACCEPT -A INPUT -p tcp --dport 443 -j ACCEPT -A INPUT -p tcp --dport 80 -j ACCEPT -A INPUT -j DROP Default ACCEPT on OUTPUT My ORPort is on 443, so I don't see how this could be interfering. I noticed my server reboot got rid of all my rules, so I'm thinking that could've been the issue. If so, what other ports should I add? Do I even need a firewall for the relay? I don't do anything else with that server, so If it doesn't need a firewall to stay secure I won't use one. One more thing, I had a flag on my relay that said I needed to "update the descriptor." It went away after rebooting my server as well, could that been the issue? Sent with [Proton Mail](https://proton.me/) secure email.

3 2

Re: [tor-relays] Relay question
by denny.obreham＠a-n-o-n-y-m-e.net 08 Dec '23

08 Dec '23

For your firewall settings, you will find everything you need here: https://github.com/Enkidu-6/tor-ddos/ It is the common setting for most Tor operators. Although, I don't think it is the source of your problem and I wouldn't worry too much about it unless it happens repeatedly. The log in "/var/log/syslog" might give you some helpful hints. Denny On 12/07/2023 10:19 PM Mulloch94 via tor-relays <tor-relays(a)lists.torproject.org> wrote .. > Greetings, I was directed to this relay subscription by the owner. I've recently > started my own relay and everything has went smooth for the first few days. Then > the relay mysteriously went offline for a period of 8-9 hours. Happened while I > was sleeping I think, but any rate it came back on after I restarted the tor daemon > and rebooted the server. I'm starting to think my firewall configurations might > have been the culprit, even though I ran a very rudimentary setup. Basically just: > -A INPUT -p tcp --dport <my SSH> -j ACCEPT > -A INPUT -p tcp --dport 9050 -j ACCEPT > -A INPUT -p tcp --dport 443 -j ACCEPT > -A INPUT -p tcp --dport 80 -j ACCEPT > -A INPUT -j DROP > > Default ACCEPT on OUTPUT > > My ORPort is on 443, so I don't see how this could be interfering. I noticed my > server reboot got rid of all my rules, so I'm thinking that could've been the issue. > If so, what other ports should I add? Do I even need a firewall for the relay? > I don't do anything else with that server, so If it doesn't need a firewall to > stay secure I won't use one. One more thing, I had a flag on my relay that said > I needed to "update the descriptor." It went away after rebooting my server as > well, could that been the issue? > > Sent with [Proton Mail](https://proton.me/) secure email.

1 0

EFF's university Tor relay campaign
by Roger Dingledine 08 Dec '23

08 Dec '23

Hi folks! EFF has launched their advocacy campaign for getting more Tor relays running at universities: https://toruniversity.eff.org/ https://www.eff.org/deeplinks/2023/08/announcing-tor-university-challenge https://www.eff.org/press/releases/eff-launches-tor-university-challenge We're focusing on universities in particular, not just to get more capacity for the Tor network, but also to strengthen the connections between the Tor network and academia. Universities are great locations for Tor relays for education (Tor is part of every cybersecurity curriculum these days), for community (growing connections between students and research groups), and for research (helping the Tor network stay strong so people can use it for research): https://toruniversity.eff.org/administrators/ https://blog.torproject.org/tor-heart-pets-and-privacy-research-community/ Having more relays at universities is especially useful because it can help others to see that running a relay is a normal and straightforward thing to do. So: if you are at a university, or you know somebody who is and want to help them, please consider setting up relays there. It can be anything from an exit relay (the most useful to Tor users, but the most work in terms of local advocacy and relationship-building), to a non-exit relay (still very useful to Tor users, because we need more network diversity), to a non-NATed Snowflake bridge (currently used most by people in Iran to get around their censorship and reach the Tor network). We started the campaign with thirteen institutions that are already running relays and/or other public infrastructure pieces: Technical University Berlin (Germany) Boston University (US) University of Cambridge (England) Carnegie Melon University (US) University College London (England) Georgetown University (US) Johannes Kepler Universität Linz (Austria) Karlstad University (Sweden) KU Leuven (Belgium) University of Michigan (US) University of Minnesota (US) Massachusetts Institute of Technology (US) University of Waterloo (Canada) Hopefully this list will make you impressed / excited / jealous and you will want to get your university onto it. :) Later steps in the campaign will be to understand which universities have IT departments that understand and value Tor, and which ones try to block you from using Tor on their network or block Tor users from reaching their webservers. We are also imagining to do an OONI workshop to help people do "how well does Tor work on this network" tests. Here is the internal coordination/roadmap ticket if you want to follow along in detail: https://gitlab.torproject.org/tpo/community/relays/-/issues/67 Thanks! --Roger

2 3

Correction to Good Bad ISPs, UK
by code9n＠pm.me 02 Dec '23

02 Dec '23

Hi, This is probably the wrong place but here is a minor update to the Good / Bad ISPs page: http://xmrhfasfg5suueegrnc4gsgyi2tyclcy5oz7f5drnrodmdtob6t2ioyd.onion/relay… The company HostWorld in the UK does allow guard and middle relays but just refused me permission to change mine to an exit node. That's today, 2023-12-02. They're pretty good, I've had no problems, efficient customer support, unlimited bandwidth, but 'no' to exit relays. I don't know about bridges. ASN : AS42831. regards,

1 0

recommended way to run 0.4.7 on armhf?
by ilf 25 Nov '23

25 Nov '23

What's the recommended way to run 0.4.7 on armhf? > The package repository [deb.torproject.org] does not offer 32-bit ARM > architecture (armhf) images (yet). https://support.torproject.org/apt/tor-deb-repo/ Debian has 0.4.7 in bullseye-backports. But Raspbian doesn't have bullseye-backports: http://raspbian.raspberrypi.org/raspbian/dists/ -- ilf If you upload your address book to "the cloud", I don't want to be in it.

3 6

obfs4 bridge current setup is not entirely clear
by s7r 13 Nov '23

13 Nov '23

Hi, I ran into some new IP space and I decided to change a cluster of obfs4 bridges that are more than 4 year old. When I set them up I don't remember spending so much time. So, Debian latest and Tor latest from deb.torproject.org nightly. GoLang from the official website (as it's the latest version) and obfs4proxy cloned from its default git repository. 1. The page at https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ needs a small revision. This page must be changed, for Debian it doesn't work simply $ edit tor@.service tor(a)default.service , change to NoNewPrivileges=no, save and quit. For me it only worked by editing /lib/systemd/system/tor@.service and /lib/systemd/system/tor(a)default.service with NoNewPrivileges=no and then: $ sudo systemctl daemon-reload. Setcap command is ok but it also need to mention to install the package in Debian libcap2-bin as well as an additional step: Under Debian, if obfs4proxy is installed in a different place, for example like in its git documentation /usr/local/bin/obfs4proxy then you also need to edit this file: /etc/apparmor.d/abstractions/tor and add one line (or change the default obfs4proxy line to): /usr/local/bin/obfs4proxy Pix, Substitute path if different and then: $ sudo systemctl restart apparmor. ------------------------------------------------ 2. It was recommended on the mail list that obfs4 bridges should not open their ORPorts publicly to prevent scanning the entire 1-65536 port range and determine it's a Tor bridge. OK. But if you try: ORPort 127.0.0.1:auto ORPort [::1]:auto AssumeReachable 1 # needed to skip ORPort reachability test Tor will start but it will constantly complain in the log with: [warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address REAL_IPv4_ADDRESS. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'. [warn] The IPv6 ORPort address ::1 does not match the descriptor address REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use 'Address <IPv6>' and 'OutboundBindAddress <IPv6>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'. I guess it's OK to continue to run it even with this as I do understand the log messages and it's the desired effect, but isn't it confusing for less experienced users? They might think something is wrong when it is not. The recommended way is to add a simple logic to skip that check, because we can't remove it, it's vital necessary for relays (not bridges) behind NAT or dynDNS or whatever. So if BridgeRelay 1 is set and $some_transport enabled, ignore the ORPort and descriptor check / log. and instead check the pluggable transport if port open and listening. Or even better, code a pluggable transport port reachability test before building and uploading the descriptor, by cloning the code that does this for ORPorts to the pluggable transport ports. This would need a proposal that covers all use cases. 3. ServerTransportListenAddr can be used just once and it's difficult for dual-stack which is now the vast majority. It's known for many years that each pluggable transport supports just one ServerTransportListenAddr line, the second one is simply ignored. Tickets for this exist. So what is the best way to for an user to open both IPv4 and IPv6 pluggable transport ports? In Debian I have achieved it by using as wildcard ServerTransportListenAddr [::]:80 since the wildcard [::] under Debian binds to all IPv4 and IPv6 addresses on all interfaces, but this might not be the same for all operating systems. Also, how does BridgeDB determine in case wildcard [::] is used if the pluggable transport is IPv4, IPv6 or both? Which one is used when BridgeDB sends this bridge to clients?

3 4

Relay no longer acting as a gaurd node?
by Jonathan Proulx 12 Nov '23

12 Nov '23

Hi All, A little while ago one of my relays switched from usually acting as a guard node to never acting as a guard node: https://metrics.torproject.org/rs.html#details/9715C81BA8C5B0C698882035F75C… Doesn't matter to me if it's a guard or not jsut want to understand what's changed and if it's a problem. Do I have a misconfiguration? -Jon

6 5

"Failed to find node for hop #1 of our path"
by William Denton 12 Nov '23

12 Nov '23

Lately my relay hasn't been seeing much traffic, which I didn't notice for a while, but now I'm turning my attention to it. I just updated to 0.4.8.9 and see these notices (with some lines cut out): [all the startup stuff looks normal, ending with success] Nov 09 13:07:31.000 [notice] External address seen and suggested by a directory authority: 24.212.137.85 Nov 09 13:08:29.000 [notice] Self-testing indicates your ORPort 24.212.137.85:9001 is reachable from the outside. Excellent. Publishing server descriptor. Nov 09 13:10:39.000 [notice] Performing bandwidth self-test...done. [but then] Nov 09 13:36:42.000 [notice] Tor has not observed any network activity for the past 521 seconds. Disabling circuit build timeout recording. Nov 09 13:38:03.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. Nov 09 13:38:03.000 [notice] Our circuit 0 (id: 151) died due to an invalid selected path, purpose Hidden service: Pre-built vanguard circuit. This may be a torrc configuration issue, or a bug. Nov 09 13:39:24.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. Nov 09 13:40:10.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. [later] Nov 09 14:01:27.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. Nov 09 14:01:34.000 [notice] Tor now sees network activity. Restoring circuit build timeout recording. Network was down for 2013 seconds during 43 circuit attempts. Nov 09 14:02:35.000 [notice] No circuits are opened. Relaxed timeout for circuit 2627 (a Measuring circuit timeout 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. Nov 09 14:02:44.000 [notice] Tor has not observed any network activity for the past 66 seconds. Disabling circuit build timeout recording. Nov 09 14:04:03.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. Nov 09 14:06:24.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit. There are hundreds of those notices about failing to find a node for hop #1. (I don't know why it complains about the network being down to 2013 seconds (over half an hour), because I didn't notice anything, but there were scores of the same warnings before that.) What would cause this, or what could I do to identify the problem? Bill Denton -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada CO₂: 419.18 ppm (Mauna Loa Observatory, 2023-11-07)

2 1

Re: [tor-relays] Relay no longer acting as a gaurd node?
by denny.obreham＠a-n-o-n-y-m-e.net 12 Nov '23

12 Nov '23

On 11/9/23 16:03, Jonathan Proulx wrote: > A little while ago one of my relays switched from usually acting as a > guard node to never acting as a guard node: > > https://metrics.torproject.org/rs.html#details/9715C81BA8C5B0C698882035F75C… > > > Doesn't matter to me if it's a guard or not jsut want to understand > what's changed and if it's a problem. Do I have a misconfiguration? I had a similar event about a month ago and everything came back to normal on its own. I found that the following answer to my question on this mailing list was very helpful: https://lists.torproject.org/pipermail/tor-relays/2023-September/021334.html

1 0

Money for relay operators and email addresses
by code9n＠pm.me 04 Nov '23

04 Nov '23

tl;dr: Paying relay operators - yes, once it's decided how to share out the money. Requiring valid email addresses - yes. imo s. It goes against the purely altruistic bit of me to say this but I definitely see the advantage of paying relay operators. I run one pretty powerful relay on a commercial vps, costs me around $200 a year. I'd run more but the money starts to pile up . . . so if I got significant enough recompense I would run more - good for Tor. Also, has it been decided exactly how the money will be shared out? If it's on the number or relays you operate that will incentivize many slow, weak relays at the expense of a few fast, good ones - bad for Tor. If it's on advertised bandwidth, is that hack-able? It changes over time, do you take the average? The figure on accounting day? Do you go on the bytes per second? Terabytes per month? The consensus weight? Do you pay more for exit nodes as they're more 'useful', more, valuable to the network as a whole? How about guards as opposed to middle, or bridges, snowflakes, etc.? Do you reward / penalize operators for / not keeping their relays up to date, etc.? Also paying for nodes could make it more viable for three letter agencies, etc. to run more relays, but I doubt it's about money for them as much as it is for us. Or for relay abusers like those that were stealing crypto wallet creds. On the whole it's probably better for tor to pay than not to, imo, (from the relay operators donations pot). Or someone could run a DoS attack by earning a significant proportion of all the money in the pot then shutting down their relays all at once. Especially if the network grows to rely on the donations money. All of this 'sharing out donations money' thing is moot if the amount of money we'd each receive is trivial compared to the cost of running relays . . . xxxxxxxxxxxxxxxxxxxx On the subject of requiring valid email addresses, I can't see any good reason not to do so. It would be quite difficult to run a relay completely anonymously, especially if you have to pay for anything. If you can achieve that, an email address that's not link-able to you shouldn't be beyond your ability. And there are potentially occasions when Tor might want to contact you discreetly. If you're doing something foolish or wrong do you really want it pointed out in a general announcement? My only reservation would be regarding receiving spam but as, I think it was @Boldsuck, said, that's not much of an issue in practice.

1 0

Please upgrade to new Tor release 0.4.7.16 or 0.4.8.8 ASAP!
by gus 03 Nov '23

03 Nov '23

Dear relay operators, Today (2023-11-03) the Network Team has released new Tor versions 0.4.7.16 and 0.4.8.8[1]. These updates contains a fix to a remote crash bug (TROVE 2023 004). It is highly recommended that all relay operators upgrade to the new versions as soon as possible to maintain the network stability and security. For those running their Tor relay using the Tor Debian repository, expect the new deb package to be available soon. The patches prevents the issue from causing a crash in Tor. However, it will make Tor more noisy when the bug is triggered, including logging information about the remote peer that is the source or destination of the circuit in the path. Such information is important for our developers to diagnose the specific invariant within Tor's TLS logic that does not hold. Eventually, a new version of Tor will need to be released in the future that will remove the verbose logging of this issue. Please note that this bug is specific to Tor relays and does not impact Tor clients or Tor powered apps (Tor Browser, Orbot, OnionShare). Thank you, Gus [1] https://forum.torproject.org/t/security-release-0-4-7-16-and-0-4-8-8/10064 -- The Tor Project Community Team Lead

1 0

Proposal: Restrict ContactInfo to Mandatory Email Address
by Georg Koppen 01 Nov '23

01 Nov '23

Hello everyone! As indicated in our bug tracker a while ago[1] we have some strong incentives to redo our ContactInfo field. I've collected all the different use cases and combined them in a single proposal, discussing some potential concerns and future work we could get built upon it. The work is tracked on Gitlab as well[2] feel free to provide feedback there or here on the list as a follow-up to this announcement. For your convenience the proposal text is included below (if you like reading the .md file on Gitlab, see my personal repository for the latest draft[3]). """ ``` Filename: 100-contactinfo-mandatory-email-address.md Title: Restricting ContactInfo to Mandatory Email Address Author: Georg Koppen Created: 2023-10-21 Status: Open ``` ## Overview This document proposes to change the ContactInfo field from a free text field to one that is only allowing an email address. Additionally, providing such an email address will be required after this proposal is implemented. This is a normative document. ## Motivation Being able to reach out to and contact relay operators (bridge operators are included in that group) is important for our day-to-day work at Tor. While this has been brought up in the past as helpful in our fight against malicious relays, it goes well beyond that use case and is affecting general network health work, community-building efforts and quickly deploying anti-censorship related security fixes among other things. Tor is providing a `torrc` configuration option, `ContactInfo`, which is supposed to contain an email address (potentially obfuscated) under which the relay operator may be reached. However, in practise this does not work very well for two reasons: 1. `ContactInfo` is a free-form field which allows the operator to include not just email addresses but essentially any kind of text they want. This results in a lot of overhead when trying to contact all operators and failures to do so because not everything added to `ContactInfo` is a way to actually contact operators or undoing `ContactInfo` obfuscation turns out to be too hard. 2. `ContactInfo` can be empty as it is not required for all operators and in cases where it is supposed to be required (e.g. for operators running more than one relay) the requirement is not enforced. Over the years different teams at Tor developed different workarounds to the issues mentioned above without addressing them directly. The goal of this proposal is to make those workarounds obsolete. ## Fixing ContactInfo As briefly mentioned in the [Overview section](#overview) the idea of this proposal is deceptively simple: `ContactInfo` will be turned into a field allowing just an email address, under which the operator can be reached. Moreover, providing such an address will be a requirement for all operators regardless whether they run one relay or many of them, or bridges. Why will we require an email address and not, say, a domain set up somewhere or an account on our forum instead? Firstly, a lot of those other potential options require a valid email address themselves in the first place and would therefore just raise the costs for relay operators. Secondly, email still scales way better than other alternatives allowing us to reach more people in less time. And, thirdly, email addresses are required anyway in other network related infrastructure parts, e.g. the RIPE database for IP address space allocation comes to mind or abuse contacts for dealing with potentially malicious Tor traffic/Tor users. Even though this proposal will not lay out the envisioned changes at a technical level (for that to happen we'll need a corresponding [tor-spec] proposal later on) there are a number of details to consider mainly stemming from the status quo existing for years and the accumulated usage patterns of the `ContactInfo` field "in the wild". The remainder of this proposal will be devoted to explain those details and address potential concerns related to them. ## Implementation The C-Tor codebase is in maintenance mode and not accepting any new features anymore (with a very narrow set of exceptions). We therefore plan to have this change included solely in the upcoming Arti relay work. Note: while we'll be using `ContactInfo` throughout this proposal it does no mean that the respective configuration option for Arti relay will be the same. It could just be [`contact`] or something else. The important point is that this proposal applies to whatever is providing the argument for the "contact" keyword in the server descriptor then. Requiring a syntactically correct email address in an Arti relay configuration option is necessary but not sufficient for our purposes. Otherwise `ContactInfo` values like `nobody(a)example.com`, which is used by some relays and bridges in the Tor network at the time of writing this proposal, would be acceptable. However, in that case there would be no way to get into contact with respective relay operators. We intend to solve that problem by deploying an email verification service: relays without a verified `ContactInfo` value won't be allowed on the network. ## Concerns There are some concerns related to this proposal which we should discuss and address where needed. The following sections will outline them and explain why (and how) we think they are non-issues or can be mitigated. ### Backward compatibility and breakage of external tooling What do we do with `ContactInfo` strings that are not email addresses already? The main goal should be to make the transitioning process to the new `ContactInfo` string as smooth and easy for relay operators as possible. The good news is that we plan to have a transitioning tool for the overall change of C-Tor relays to Arti relays anyway and having the `ContactInfo` change be part of that should help. Running an awareness campaign and providing up-to-date documentation to reach operators that need to fix (or even set up) their `ContactInfo` manually should further minimize the risk of losing relays in the network and volunteers running them to begin with. However, even if it were possible to extract an email address from the C-Tor relay configuration of any C-Tor relay or bridge without manual intervention by the operator there is another problem to consider: there is often additional information available in current `ContactInfo` strings, which sometimes external tools got built upon. One well-known example for that is [`OrNetStats`] which aims at displaying statistics related to relays and bridges in the Tor network. One important piece of it is grouping the displayed information around so-called Authenticated Relay Operator IDs (AROIs) were possible, which got developed in the [ContactInfo Information Sharing Specification] \(CIISS) and is making use of overloading the `ContactInfo` field with additional information besides an email address. While we can't avoid breaking tools when evolving the `ContactInfo` semantics we can provide ways for those tools to get adapted to the new reality. For that we propose to create an additional configuration option that includes the non-email address information in the `ContactInfo` field and is made public in extra-info descriptors. Even though we believe validated email addresses as proposed in this proposal together with the planned [happy families proposal] and [proposal 347] provide similar benefits as the AROI mechanism, and hence make it superfluous, if someone would still like to center their relays statistics around AROIs they could do so by extracting the necessary information from extra-info descriptors after this proposal got implemented. ### Spam Exposing an email address without obfuscation in the `ContactInfo` field is a potential spam risk which is why some operators have resorted to obfuscating it, often in very creative ways. However, we do think that those efforts are not effective if we want to retain a way of being able to reach operators by email. Moreover, our own and others' experience of running relays and providing an unobfuscated email address as `ContactInfo` shows that spam right now is actually not an issue. That might change in the future, though, which is why we strongly recommend to use a dedicated and long-term email address in the `ContactInfo` field. The long-term part is particularly important, as this proposal turns that email address into a validated relay operator ID, which is valuable for building trust over the longer run. ## Impact on relay operators and the growth of trust in the Tor network As can be seen in the previous sections, the proposed changes in this document can come with a cost for relay operators. However, we do not expect them to have a lasting impact on our relay operator community and the health of the network as those changes are mainly accompanied by a one-time transition cost that puts a burden on our current relay operators. And that one-time cost we try to keep as low as possible. Additionally, we might lose or alienate some of our current and potential new operators, as they might not want to provide any (verifiable) email address at all as a requirement for running relays, but rather prefer participation anonymously. However, in order to fight malicious relays we need to strengthen our community and get to build connections and contacts with each other, which is hard if there is no way to get into contact to begin with. As outlined at the begin of this document, a lack of contact information makes other day-to-day work at Tor hard or impossible as well. Thus, overall we believe providing a working email address when running relays is a small cost compared to the improvements of the health of our network and the safety of our users. There is another benefit which comes with this proposal: the validated email address can essentially work as a relay operator ID (similar to the above mentioned AROI). While we do deal with single relays or families of them when we are trying to determine whether they pose a danger to our users, what we are ultimately aiming at is the operator behind them. Having something like a relay operator ID does help with that part. But there is more: it allows us to think better about trust on the Tor network and how we might be able to implement ideas like "operator X is only allowed to run Y% of the Tor network" or "unknown operators are only allowed to run Z% of Tor's network capacity", to name just two. There are a number of proposals both [trust][torspec 103] [related][relay-search 40001] and [not trust-related][team 220] that would benefit from having relay operator IDs available. ## Acknowledgements Big thanks go to @gus and @ahf for discussions and feedback around this proposal idea, which improved this document considerably. [tor-spec]: https://gitlab.torproject.org/tpo/core/torspec [`contact`]: https://gitlab.torproject.org/tpo/core/arti/-/issues/870#note_2906252 [`OrNetStats`]: https://nusenu.github.io/OrNetStats/ [ContactInfo Information Sharing Specification]: https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ [happy families proposal]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/82ba302230911cafd8683… [proposal 347]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/523404500320ba9700fe5… [torspec 103]: https://gitlab.torproject.org/tpo/core/torspec/-/issues/103 [relay-search 40001]: https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/iss… [team 220]: https://gitlab.torproject.org/tpo/network-health/team/-/issues/220 """ Thanks, Georg [1] https://gitlab.torproject.org/tpo/core/arti/-/issues/870 [2] https://gitlab.torproject.org/tpo/community/relays/-/issues/71 [3] https://gitlab.torproject.org/gk/policies/-/blob/prop100/100-contactinfo-ma…

3 3

Discuss. Why not split donations to Tor relay owners?
by torrrelays＠riseup.net 01 Nov '23

01 Nov '23

I provided some high speed Tor nodes (non-exits and guards) but I quit in this year to make some space for my other projects. I would continue collaborating by keep Tor nodes online if I receive some donation. Is it just me, because I received $0 for running those Tor relays. So my proposal is this: 1. make a donate-torrelay-owner.tpo website 2. let Tor relay owners link their PayPal/Striple/BitCoin/OpenCollective/AmazonPay/GooglePay/Whatever account 3. the Tor project and other good folks put money into the large bottle (donate-torrelay-owner website) 4. the donation then split by the participants & send to each accounts monthly By doing this, you are creating sustainable mechanism to keep Tor nodes running and other people who have access to their servers may join. More Tor nodes will be added to the network & owners get paid at least. Win-win. Please do this!

8 11

Re: [tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address
by denny.obreham＠a-n-o-n-y-m-e.net 31 Oct '23

31 Oct '23

On 10/31/2023 03:09 PM tor(a)nullvoid.me wrote .. > My only concern with your solution is anyone can pretend to be the owner of a relay. - What do you have to say to a relay owner that cannot be said publicly? - What do you have to say that needs a reply? In the rare cases where you would have a valid answer for the above questions, the actual email address in the ContactInfo is good enough, and - assuming there are none - you could ask to include a temporary code in the ContactInfo for authentification when someone contacts you on your request. The point is if you have to contact all relay operators, you don't need to look for their email addresses in ContactInfo. All you need is to post the message publicly, easily accessible by each relay owner (a personalized RSS feed comes to mind).

1 0

Re: [tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address
by denny.obreham＠a-n-o-n-y-m-e.net 31 Oct '23

31 Oct '23

I've been thinking long and hard about this problem and I'm not sure if an email address - validated or not - is the best way to achieve the initial goals. What are the goals of having this validated email address? 1- Inform the operator; 2- Make sure the operator will read the info; 3- Identify the operator. I'll keep #1 for last as this is the only truly needed goal from my point of view. Identifying the operator ID to make further decisions on how to share the traffic may be kind of useless. There are either _good_ operators and you have no real reason to divert traffic from these relays or there are _bad_ operators and they will try to hide that fact by creating multiple identities. Your validated IDs are still useless to you as identifying _bad_relay operators. About validating an email address to make sure the operator will read the info, it is still not a guarantee that it will happen in the future. If an operator does not want to - or cannot - read his/her emails, you cannot do anything about it. Except maybe revalidating the email address regularly which is, first, annoying and, second, what are going to do if a _good_ relay operator doesn't revalidate his/her email address? Shut down all of his/her relays? You might shoot yourself in the foot going with such an attitude. So there is no real point in validating an email. It will just turn out to be more red tape to go through. About point #1, you want to inform the relay operator. Do you need a two-way communication method for that? * How about putting the message to the operator on the _metrics.torproject.org_ relay page? * Would there be any reason for the messages not to be public? * If, somehow, a response - or an exchange - may be needed, why not put a general contact email address for answers, comments, etc. with, for example, the message ID as the subject? If the message is really personal, the message can be as simple as "Contact us at torproject(a)example.org ASAP." * Why not put an RSS feed to be able to fetch those messages automatically and regularly? * That way, you can also contact multiple operators based on their country, platform, etc. with the same message as well. This would be something similar to _weather.torproject.org_ but much simpler and without a need for any kind of registration. Are you sure all operators will follow, read, and act upon your messages? Not less than by sending an email. Much better than NOT having a valid email address at all. A _bad_ operator will be a _bad_ operator no matter what.

2 1

Next Tor Relay Operator online Meetup - Saturday, October 21 @ 19 UTC
by gus 23 Oct '23

23 Oct '23

Hello, The next Tor relay operator meetup will happen this Saturday, October 21 @ 19 UTC. Where: BBB - https://tor.meet.coop/gus-og0-x74-dzn 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. Note: BBB requires a browser that supports webRTC such as Firefox, Safari, or Chromium/Chrome. Agenda ------ https://gitlab.torproject.org/tpo/community/relays/-/issues/77 [Expected meeting duration: 60 to 90 minutes] - Announcements: - WebTunnel PT is available on Tor Browser 13 - (Update) Tor on Universities - Meta-proposal for new relay operator policies: https://gitlab.torproject.org/tpo/community/policies/-/blob/master/001-comm… - [Discussion] ContactInfo proposal Everyone is free to bring up additional questions or topics at the meeting itself. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

1 2

PSA: Exit nodes on 0.4.7.x might see less traffic
by Georg Koppen 17 Oct '23

17 Oct '23

Hello everyone! As you might have noticed, Tor Browser 13 got released last week[1] which ships for the first time a Tor 0.4.8.x version (0.4.8.7) to our stable Tor Browser users. One of the main features in the 0.4.8.x series is Conflux, which allows traffic-splitting to improve Tor performance.[2] Given that we assume Tor Browser users are a large fraction of our overall Tor users and 0.4.8.7 deployed by Tor Browser results in pre-built Conflux circuits, there is a chance that exit nodes on 0.4.7.x might see less traffic over time. An easy way to avoid or fix that problem is an upgrade to the 0.4.8.x series. Georg [1] https://blog.torproject.org/new-release-tor-browser-130/ [2] https://gitlab.torproject.org/tpo/core/torspec/-/blob/288c5134ddb737e321cf3…

1 0

Relay Bandwidth Limit
by Dan 16 Oct '23

16 Oct '23

Hi all, I’ve been running my first relay for a few weeks now. The VPS provider I chose provides 5TB of bandwidth per month so I have set AccountingMax to “5 TB” and AccountingStart to

6 7

snowflake prometheus metrics listen address
by Fran 03 Oct '23

03 Oct '23

Hey there, snowflake v2.6.1 offers a prometheus metrics endpoint `-metrics`.[1] Unfortunately I am unable to figure out how to let it listen to non-localhost address: tcp LISTEN 0 4096 127.0.0.1:9999 0.0.0.0:* users:(("snowflake",pid=402248,fd=6)) Any ideas? Thansk! f. [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

2 2

Does Tor itself estimate how it can run as quota-utilizing as possible?
by telekobold 01 Oct '23

01 Oct '23

Hello together, today I apparently discovered an interesting feature of Tor I wasn't aware of: I'm running two relays at a large provider's data center having 20TB/month free outgoing traffic for each relay. However, this quota is often exhausted before the end of a month. In order to provide the Tor project with some bandwidth all the time, I configured "AccountingMax 20 TB" and "AccountingStart month 1 00:00" and, for the last few months, I used to switch off one of the relays on the first of a month and turn it on again a few days after the beginning of the month, so that one of the two relays is running all the time. I also connected the two relays using the "MyFamily" flag. Until last month, each of the relays simply continued to run after the end of the month. Today, however, I wondered why one of the relays shut itself down apparently which did not change after a restart. A look into /var/log/tor/notices.log provided the following entries: Oct 01 16:58:29.000 [notice] Configured hibernation. This interval began at 2023-10-01 00:00:00; the scheduled wake-up time is 2023-10-05 06:06:25; we expect to exhaust our quota for this interval around 2023-10-29 04:23:25; the next interval begins at 2023-11-01 00:00:00 (all times local) [...] Oct 01 16:58:49.000 [notice] Commencing hibernation. We will wake up at 2023-10-05 06:06:25 local time. Oct 01 16:58:49.000 [notice] Going dormant. Blowing away remaining connections. So apparently Tor learned from my behavior and calculated itself when to turn itself off and on again in order to use as much quota as possible based on the bandwidth used and/or some other metrics so I don't have to do this manually in future? Kind regards telekobold

2 2

Bridge with iat-mode=2 very slow
by Split 28 Sep '23

28 Sep '23

Hello everyone! I run the obfs4 bridge, in the parameters I specify to use iat-modr=2. As a result, the bridge is VERY, VERY SLOW. Connection speed is on average 100 kb/sec. When I remove the iat-mode=2 parameter, the speed becomes 8-10 times higher. I checked the processor load, it is at 3%, the problem is unlikely to be with the processor, the RAM load is at 20%. I can't figure out if this is expected behavior or if the speed drop is too significant. Please tell me, is this the normal maximum speed of the bridge with iat-mode=2 or can it be increased somehow?

3 2

Tor Weather : Node-Flag [Guard] Alert
by denny.obreham＠a-n-o-n-y-m-e.net 27 Sep '23

27 Sep '23

I received the following message from Tor Weather. According to Tor Metrics, this exit relay still has no Guard flag. Another - slightly more recent - exit relay (25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57) is on the same server and IP, and still has the Guard flag (although with 0% guard probability). Should I do something with this info? Denny On 09/26/2023 06:31 PM weather(a)torproject.org wrote .. > > > Hi, > > We have detected that the node - 3B85067588C3F017D5CCF7D8F65B5881B7D4C97C associated > with your subscription has lost the Guard flag > for more than 1hr(s). This may impact the performance of your service. > > Thank You!

2 1

Grafana dashboards
by Toralf Förster 16 Sep '23

16 Sep '23

Yesterday I stumbled together 2-3 dashboards [1] for Tor relay(s), Tor Snowflake(s) and the DDoS solution [2]. Feedback is welcome. [1] https://github.com/toralf/torutils/tree/main/dashboards [2] https://github.com/toralf/torutils/tree/main -- Toralf

1 0

Metrics
by BridgeOverStyx 08 Sep '23

08 Sep '23

My bridge styxVortex is up and running. I know this because the Nyx monitor shows activity. However, a search of metrics.torproject.org shows it down. It has been in this state for at least a month. Do you have any suggestions of what could be the possible cause of this? I am using pfblockerng on my network, but the machine that is running Tor bridge is not filtered by it. I do have a couple of TOR feed enabled in pfblockerng but only incoming traffic is filtered. I have no idea how the bridge stats are passed to metrics.torproject.org so it is very challenging for me to tamp down on the cause. Any suggestion, at this point, will be helpful. Sent with [Proton Mail](https://proton.me/) secure email.

6 9

Quick bugfix sharing regarding obfs4 malfunctioning
by telekobold 07 Sep '23

07 Sep '23

Hi, I just want to share some quick bugfix with you (sorry if this is obvious to you or has been written somewhere else). Suddenly, I got the following error messages on my two bridges running on Debian 11 appearing in the logs (in /var/log/tor/notices.log and in the nyx output) every second until a restart: <timestamp> [warn] Managed proxy "/usr/bin/obfs4proxy" process terminated with status code 65280 <timestamp> [warn] Server managed proxy encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied) <timestamp> [warn] Managed proxy '/usr/bin/obfs4proxy' was spawned successfully, but it didn't launch any pluggable transport listeners! When restarting the corresponding bridge, in the startup process the second and the third of the above warning messages again appeared in the logs. So obfs4 was suddenly not usable any more. Port 443 is not blocked in the bridge's firewalls. A bit research reveled that apparently, an automatic update set the systemd setting "NoNewPrivileges=no" in /lib/systemd/system/tor(a)default.service and tor@.service [1] back to yes, which caused the above issue. After setting it back and restarting, everything works fine now and instead of the warning messages mentioned above, the following message appears in the log again: <timestamp> [notice] Registered server transport 'obfs4' at '[::]:443' (Several places recommend to set the obfs4 port to 443 to get around restrictive firewalls, so I didn't want to set it to something else). Kind regards telekobold [1] http://xmrhfasfg5suueegrnc4gsgyi2tyclcy5oz7f5drnrodmdtob6t2ioyd.onion/relay…

3 2

(Last call) Bridges running obsolete Tor version (0.4.5.x) to be removed soon
by gus 05 Sep '23

05 Sep '23

Hi bridge operators, Serge, the Bridge Authority is about to update their Tor version to 0.4.8.5 and it will reject bridges running the Tor version 0.4.5.x. Please upgrade your bridge if you're running an outdated version (0.4.5.x) ASAP. List of outdated bridges: https://metrics.torproject.org/rs.html#search/type:bridge%20version:0.4.5%20 Thanks for helping censored users to bypass censorship! cheers, Gus -- The Tor Project Community Team Lead

2 1

relayor v23.2.0 is released
by nusenu 28 Aug '23

28 Aug '23

Hi, relayor v23.2.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… This release includes new prometheus alert rules so you do not forget to renew your relay certificates before they expire. This feature requires tor version 0.4.8 though which is unfortunately not yet available on deb.torproject.org stable repos. It also includes rules that alert you if your exit relay has an unhealthy DNS timeout fraction or if your relay is dropping onionskins for at least 15 minutes. Changelog: https://github.com/nusenu/ansible-relayor/releases/tag/v23.2.0 kind regards, nusenu -- https://nusenu.github.io

1 0

Exit Relays: What is your DNS timeout rate?
by nusenu 26 Aug '23

26 Aug '23

Hi, the upcoming relayor release will contain new prometheus alert rules that should help operators detect/mitigate/prevent some common operational issues. One of these rules will alert on high DNS timeout rates [1] on exit relays that should be investigated and resolved to improve the Tor Browser experience for users. To define the default alert threshold it would be relevant to know current timeout rates by multiple exit operators. So if you feel up to it you can send me (off-list) your current timeout rates (30 day graph): If you run tor exits with relayor and MetricsPort enabled you can use these Prometheus queries: timeout percentage by server: (sum by (instance)(rate(tor_relay_exit_dns_error_total{reason="tor_timeout"}[15m])))/(sum by (instance)(rate(tor_relay_exit_dns_query_total[15m])))*100 DNS query rate: sum by (instance)(rate(tor_relay_exit_dns_query_total[15m])) If you run exits without relayor you can use these queries: (sum by (job)(rate(tor_relay_exit_dns_error_total{reason="tor_timeout"}[15m])))/(sum by (job)(rate(tor_relay_exit_dns_query_total[15m])))*100 sum(rate(tor_relay_exit_dns_query_total[15m])) kind regards, nusenu [1] https://github.com/nusenu/ansible-relayor/commit/9b6937563ec0b41e6abb0217ed… -- https://nusenu.github.io

1 0

Wrong "first seen" flag for bridges at metrics.torproject.org
by telekobold 23 Aug '23

23 Aug '23

Hi together, I have an issue regarding the "first seen" flag at metrics.torproject.org: It is definitely wrong for my two bridges - both dates are much too close in the past. For one of the bridges, it seems to correspond to the last signing key renewal, for the other bridge, it seems to correspond to the penultimate signing key renewal. Has anyone observed similar behavior for its relay? (I found it meaningful to first ask here before creating an issue at [*]). [*] https://gitlab.torproject.org/hiro/onionoo/-/issues Kind regards, telekobold

3 2

Tor-Bridge
by tor＠pqpera.xyz 19 Aug '23

19 Aug '23

Possible compression bomb; abandoning stream. <- Happened to my server for 2h straight. Should I take any measures against that? Bridge is obsf4 with fingerprint: 2EA91C1415C421424BB478A55790E655627DE366.

2 1

Tor Relay in Kubernetes cluster
by Daniel Nikoloski 18 Aug '23

18 Aug '23

Hi all, Is anyone running Tor relay in k8s cluster? I am trying for a few days but It does not come alive. My servers are not behind a firewall, should be and are accessible, I run two bare-metal servers in Contabo. 1 master 1 node. Docker image and helm chart that use; https://gitlab.com/nikoloskid/tor-server The logs I get; > Aug 05 21:04:55.000 [notice] Now checking whether IPv4 ORPort 38.242.233.101:32150 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) > Aug 05 21:24:45.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at 38.242.233.101:32150. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports > > , address, /etc/hosts file, etc. When i try telnet it is open to the internet > telnet 38.242.233.101 32150 > Trying 38.242.233.101... > Connected to 38.242.233.101. > Escape character is '^]'. You can see the service here; https://gitlab.com/nikoloskid/tor-server/-/raw/helm-chart-tor-relay/tor-ser… /etc/tor/torrc; > Nickname icebergk8s > Address 38.242.233.101 > ContactInfo nikoloskid(a)pm.me > RelayBandwidthRate 3.5MB > RelayBandwidthBurst 5MB > MaxAdvertisedBandwidth 5MB > ORPort 9001 NoAdvertise IPv4Only > ORPort 32150 NoListen IPv4Only > SocksPort 0 > ExitPolicy reject *:* > User debian-tor > DataDirectory /var/lib/tor Lep pozdrav / Best Regards, Daniel Nikoloski

2 1

Tor Relay Operator meetup @ CCCamp 2023 - Saturday 19th @ 7pm
by gus 17 Aug '23

17 Aug '23

Hello, The Tor Relay Operator Meetup - Chaos Communication Camp-2023[1] will happen at Bornhack (Cold North Village)[2] on Saturday, August 19th at 7pm (local time). After the meetup, we invite everyone to stay and have beer and drinks at Bornhack. Please spread the message. We have Tor stickers for you! :) Gus [1] https://events.ccc.de/camp/2023/infos/ [2] Coordinates: 53.0314175, 13.3065457 https://map.events.ccc.de/camp/2023/map/#20/53.03143/13.3066 -- The Tor Project Community Team Lead

2 4

WebTunnel: What ASNs/networks work best?
by tor-home at encryptfirst.com 17 Aug '23

17 Aug '23

When running a WebTunnel bridge, what types of IPs are better for serving requests? My background is with self-hosted home-lab type of setups. There are a number of different ways for homelabs to accept inbound https connections. A few examples: - Forward a port on a home router. - Rent a cloud VM/VPS and tunnel a port from the VPS's IP. - Have a CDN tunnel/forward requests. - VPN hybrid solutions like Tailscale Funnel. Are any of these better than others for hosting a WebTunnel bridge? Should cloud provider IPs be preferred over residential IPs, for example, considering that is where most web servers are hosted? Are large CDNs preferred over individual cloud VMs? Is it better to use a different IP for WebTunnel than the IP that runs the OR port (i.e. host OR port on home IP and WebTunnel from a cloud-based IP)? I'm mainly asking to determine which way helps the broadest number of Tor users. And which is less likely to be blocked in the future. What are the best practices? PS: Thanks for the webtunnel-bridge Docker image and the documentation on how to run it. It was very helpful and made setup easy.

4 4

Running an exit relay in Italy
by Eldalië 17 Aug '23

17 Aug '23

Hello there and thanks everyone for your answers to my message about middle relay blocking. Reading them I feel trying to solve the blacklisting of my IP would be overkilling. Since I have a chance to get a cheap VPS, I will try to migrate the relay on it. And since the relay would be on a dedicated IP, I'm thinking about making it an exit. Of course I must consider the law, and I'd like to read some references and listen about experiences from other operators before seeking professional (expensive, I guess) legal advice. My concerns are the following, but I would appreciate any other thoughts as well. The relay would be in Italy so Italian and EU laws apply. 1. Would I bear any responsibility for the use of the relay? I'm aware of the "mere conduit" concept (that is applied in the EU too) but Italy may have some crappy additional law I'm not aware of. 2. Would I be subject to any data retention or data monitoring obligation? 3. Would I be subject to any user identification obligation? 4. Would I risk the police knocking on my door even if the relay runs on a datacenter and not on my home network? Thanks, Eldalië -- Eldalië My private key is attached. Please, use it and provide me yours!

2 1

(EVENT) Tor Relay Operator Meetup - June 24, 2023 @ 18.00 UTC
by gus 10 Aug '23

10 Aug '23

Hello, The next Tor Relay Operator Meetup will happen on June 24, 2023, at 18.00 UTC. We're working on the agenda here: https://pad.riseup.net/p/tor-relay-op-meetup-june-keep onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… Feel free to add other topics to the agenda. 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! cheers, Gus -- The Tor Project Community Team Lead

5 7

short conntrack DDoS attack
by Toralf Förster 09 Aug '23

09 Aug '23

Few days ago the throughput of my Tor relay went down to nearly zero for about 3 minutes. It turned out that the reason (maybe) was a change here in my iptables rules. Especially I switched these 2 lines: iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT and run then few hours later into problems. And switched back ofc. An explanation for the dropdown was given in [1]. Given that the explanation is right: How is the Tor application harmed if an attacker mangles packets so that the state of them are INVALID for the conntrack module but they do pass the RELATED,ESTABLISHED rule ? [1] https://forums.gentoo.org/viewtopic-p-8798034.html -- Toralf

2 1

Re: [tor-relays] Middle relay IP blocking
by torserver 08 Aug '23

08 Aug '23

Roger, I had the same problem with 3 financial websites blocking my IP address while running a middle relay. Exactly 5 days after stopping the relay these sites can be reached again. They probably use the same mechanism, visible in the TPRB Firefox plug-in. I run my home relay on a low energy consuming Raspberry Pi. Why is there no perfectly detailed instruction to install a relay on the Raspberry? With its built-in VNC it can be managed by SSH and remote desktop perfectly. Then there is no need for data congestion on a few cheap providers. One Watt power consumption only costs 3 Euros a year. Snowflake almost uses no data with a few occasional users. I 'd like to use my 100 Megabits more efficient. Regards, me. > Date: Tue, 8 Aug 2023 02:32:03 -0400 > From: Roger Dingledine <arma(a)torproject.org> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Middle relay IP blocking > Message-ID: <ZNHhY1rj8rQAId0y(a)nogrod.csail.mit.edu> > Content-Type: text/plain; charset=us-ascii > > On Mon, Aug 07, 2023 at 11:28:32PM +0300, s7r wrote: > > While all the above is true, a thing to remember is to make sure we don't > > end up all renting too many VPS'es or dedicated servers in the same places / > > same AS numbers - we need network diversity, it is a very important factor, > > more AS numbers, more providers, more physical locations, etc. So, running > > at home is super good and recommended from this perspective, provides us > > with the diversity we need, however not being to login to online banking to > > pay an electricity bill because of a middle relay is also way too annoying.. > > however who can afford the hassle should definitely run a middle relay or > > bridge at home > > Yes, exactly this. If you are interested in running a non-exit relay at > home, and you can tolerate the hassles from occasionally finding that > some service doesn't want to hear from you, then you are definitely > helping the diversity of the Tor network. > > Having the Tor traffic concentrated at a few cheapo providers like Hetzner > and OVH is not only scary in the sense that too much traffic goes through > too few cables, but it's also scary because it increases the appeal for > somebody to attack those few companies, either by breaking into their > infrastructure to watch traffic or through more traditional insider > threats like getting an employee there to help them monitor traffic. > > The internet already has uncomfortably many bottlenecks -- too few > undersea cables, too few Content Distribution Networks (CDNs), too few > app stores, etc. > > > (even Exit relay, I do run an Exit relay at my office place > > and I had one police visit in like 8 years or so). > > Follow this advice only with great caution. :) Many people happily > run their exit relay from their home, but it only takes one fresh new > cybercrime detective (trying to make a name for himself by kicking down > a door at 7am, and with no idea what Tor is) to ruin your day. > > --Roger > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ------------------------------ > > End of tor-relays Digest, Vol 151, Issue 9 > ******************************************

2 2

Middle relay IP blocking
by Eldalië 08 Aug '23

08 Aug '23

Hello there! I've been running for over 1.5 year a middle relay on an IP address I also use to browse, withous issues. However it's now some weeks since many websites that always refused tor traffic started to also refuse normal traffic from my IP. I suppose this is related to the relay, because I don't run any other "suspect" service on this IP and when I change it the problem is gone for a few hours. My guess is that some widely used black list started including middle relay IPs, but I have no proofs. Has anyone had similar experiences? Any thoughts on this? Thanks, Eldalië -- Eldalië My private key is attached. Please, use it and provide me yours!

12 15

Help Turkmens to bypass Internet censorship: run an obfs4 bridge!
by gus 02 Aug '23

02 Aug '23

Dear Relay operators community, The parliamentary elections in Turkmenistan are coming up very soon on March 26th[1], and the Turkmen government has tightened internet censorship and restrictions even more. In the last few months, the Anti-censorship community has learned that different pluggable transports, like Snowflake, and entire IP ranges, have been blocked in the country. Therefore, running a bridge on popular hosting providers like Hetzner, Digital Ocean, Linode, and AWS won't help as these providers' IP ranges are completely blocked in Turkmenistan. Recently, we learned from the Anti-censorship community[2] and via Tor user support channels that Tor bridges running on residential connections were working fine. Although they were blocked after some days or a week, these bridges received a lot of users and were very important to keep Turkmens connected. How to help Turkmens to access the Internet =========================================== You can help Turkmens to access the free and open internet by running an obfs4 Tor bridge! But here's the trick: you need to run it on a residential connection -- you won't need a static IPv4 --, and it would ideally be run on more robust hardware than just a Raspberry Pi (although that can help, we have found they can get overloaded). You can set up an obfs4 bridge by following our official guide: https://community.torproject.org/relay/setup/bridge/ After you setup a new bridge, you can share your bridge line with the Tor support team at frontdesk(a)torproject.org, and we will share it with users. A complete bridge line is composed of: IP:OBFS4_PORT FINGERPRINT cert=obfs4-certificate iat-mode=0 Check this documentation to learn how to share your bridge line: https://community.torproject.org/relay/setup/bridge/post-install/ Just sharing your bridge fingerprint is not the best, but it's fine. You can read more about censorship against Tor in Turkmenistan here: - https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… - Snowflake blocked: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… Thank you for your support in helping to keep the internet free and open for everyone. Gus [1] https://en.wikipedia.org/wiki/2023_Turkmen_parliamentary_election [2] https://ntc.party/c/internet-censorship-all-around-the-world/turkmenistan/17 https://github.com/net4people/bbs/issues/80 -- The Tor Project Community Team Lead

7 24

How do I set up a conjure Bridge?
by Poojith Bestha 01 Aug '23

01 Aug '23

I have a question. How do I set up a conjure bridge? Is the process hard? What hardware do I need to use? Regards, Poojith

2 1

Receiving abuse reports for Non-Exit Relay
by admin＠prsv.ch 01 Aug '23

01 Aug '23

Hello all, In the past 24 hrs, I have been receiving complaints from my hosting provider that they're receiving hundreds of abuse reports related to port scanning. I have no clue why I'm all of the sudden receiving abuse reports when this non-exit relay has been online for months without issues. In addition, I have other non-exit relays hosted by the same provider with no issues and more across other providers. I proceeded to reinstall the OS and reconfigure Tor. I was then quickly notified by my hosting provider again of more abuse reports all showing port 22 as target port. I have not changed my torrc at all and it's still setup as a non-exit relay. No other applications/services were installed alongside Tor. Tor Metrics does not show the relay as Exit either. It feels like Tor Exit Traffic is leaking through my non-exit relay? Has anyone else experienced any behavior similar to this? Any ideas on how to fix or prevent this? prsv admin

7 7

Re: [tor-relays] tor-relays Digest, Vol 150, Issue 13
by amanyaz Amangeldiyew 01 Aug '23

01 Aug '23

Hi. Everybody. In Turkmenistan these IPs are open: 96.233.128.72 167.62.193.195 108.50.165.220 71.33.251.73 99.232.152.8 108.184.202.115 108.34.184.5 99.230.178.2 108.184.201.30 71.212.129.108 88.22.43.218 67.6.147.5 79.16.171.221 79.113.212.117 88.91.78.20 172.88.64.65 67.251.118.15 41.109.196.229 96.237.186.35 95.31.20.151 71.113.184.94 151.225.43.243 141.255.66.158 88.19.75.220 67.11.187.237 67.6.182.48 95.252.250.216 67.6.161.111 95.236.84.157 143.107.229.252 92.194.57.57 I think for now port 8080 is open too. Can anybody make obfs4 server with these ips and port 8080? On Mon, Jul 31, 2023 at 5:01 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. Re: Help Turkmens to bypass Internet censorship: run an obfs4 > bridge! (lists(a)for-privacy.net) > 2. Re: Help Turkmens to bypass Internet censorship: run an obfs4 > bridge! (Gary C. New) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 30 Jul 2023 23:30:26 +0200 > From: lists(a)for-privacy.net > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Help Turkmens to bypass Internet censorship: > run an obfs4 bridge! > Message-ID: <2156503.WeTp2EQoyn@t520> > Content-Type: text/plain; charset="us-ascii" > > On Freitag, 21. Juli 2023 18:07:35 CEST gus wrote: > > > New update: In the last few weeks, internal political conflicts and > > other events[1] in Turkmenistan have led to another wave of censorship > > on Tor and anti-censorship tools. Tor bridges have been one of the few > > free alternatives for people in Turkmenistan to connect with the world > > and access the open Internet. > > > > I stopped snowflake and now a bridge is running on my dynIP. > > > > > ## torrc example > > > > BridgeRelay 1 > > ORPort 127.0.0.1:auto > > AssumeReachable 1 > > ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy > > ServerTransportListenAddr obfs4 0.0.0.0:8080 > > ExtORPort auto > > Nickname helptm > > ContactInfo <please-add-your-email-here> > > Log notice file /var/log/tor/notices.log > > # If you set BridgeDistribution none, please remember to email > > # your bridge line to us: frontdesk(a)torproject.org > > BridgeDistribution none > > But I have that in the log :-( > Jul 30 16:48:29 t520 Tor-01[93466]: The IPv4 ORPort address 127.0.0.1 does > not match the descriptor address 203.0.113.18. If you have a static public > IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you > are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and > 'ORPort <InternalPort> NoAdvertise'. > Jul 30 16:48:29 t520 Tor-01[93466]: The IPv6 ORPort address ::1 does not > match the descriptor address 2001:db8:1234:1:bbbb:eeee:eeee:ffff. If you > have a static public IPv4 address, use 'Address <IPv6>' and > 'OutboundBindAddress <IPv6>'. If you are behind a NAT, use two ORPort > lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> > NoAdvertise'. > > I don't know if I should ignore that or better configure it that way: > ORPort 127.0.0.1:8443 NoListen > ORPort 8443 NoAdvertise > ORPort [::1]:8443 NoListen > ORPort 8443 NoAdvertise > > I'm aware of > https://gitlab.torproject.org/tpo/core/tor/-/issues/40208 > I hope to get it done with scipting on my Mikrotik, or switch to ipv4 only. > > frontdesk(a)torproject.org has no PGP key, can I send you or meskio the > bridgeline? > > Bridgeline must be: > Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=abra+kadabra iat-mode=0 > But DynIP changes every few days. Do you also give the bridge users > myrouter.example.net? > > Because of your post in the forum: > https://forum.torproject.org/t/orport-127-0-0-1-auto/8470 > should we do this with all running bridges, or only the hidden ones? > > -- > Ciao Marco! >

1 1

(no subject)
by amanyaz Amangeldiyew 27 Jul '23

27 Jul '23

Hi. I am from. Turkmenistan. I have obtained obsf4 bridge from internet but only ip address is readable. If anybody knows fully obsf4 bridge please send me to my mail. Ip address is: obsf4 93.104.161.141

1 0

Final Call: Last Opportunity to Participate in the Tor Update Survey - Closes Tomorrow!
by Meitong Wang 22 Jul '23

22 Jul '23

Dear Tor Relay Operators, We hope this email finds you well. This is our final outreach regarding the Tor Update Survey, and we want to extend a sincere thank you to those who have already participated. Your valuable contributions have been invaluable to our research project at the University of Edinburgh. For those who haven't had the opportunity to take part yet, we wanted to remind you that the survey will be closing tomorrow, the 23rd of July. If you are interested in sharing your insights towards updates as a Tor relay operator, we kindly request you to participate now and make your voice heard. Your participation in this survey is crucial for understanding the challenges and developments within the Tor network. Your responses will be treated with the utmost confidentiality, and all data will be anonymized to ensure your privacy. Taking the survey will take approximately 10 minutes, and we genuinely appreciate the time and effort you invest in contributing to this research. To participate, please click on the following link: https://cryptpad.fr/form/#/2/form/view/dvbbDORTjeztLzosbOuGVaRheI-FBjFh6xPQ… Once again, we would like to express our gratitude for your interest and support in this project. Your input will contribute to the continued growth and improvement of the Tor network. If you have already participated or are unable to participate at this time, we sincerely thank you for considering our invitation. Should you have any questions or require further information, please do not hesitate to reach out to us. Thank you, and we truly appreciate your attention to this matter. Best regards, Meitong Wang & Tariq Elahi The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.

1 0

Friendly Reminder: Tor Relay Operators' Survey Closes on 23rd July - Last Chance to Participate!
by Meitong Wang 19 Jul '23

19 Jul '23

Dear Tor Relay Operators, We hope this email finds you well. We are writing to provide a friendly reminder that our Tor Update Survey, conducted as part of the University of Edinburgh Research Project, will be closing on 23rd July. If you haven't already participated, this is your last chance to share your invaluable insights and experiences as a Tor relay operator. Your input is critical to our research and will play a significant role in understanding the challenges in the Tor network's update process. Your responses are entirely confidential, and all data will be anonymized to ensure your privacy. We truly appreciate your willingness to contribute to this research. The survey will take approximately 10 minutes to complete, and your input will shape the future improvements and enhancements of the Tor network update design. We understand how busy schedules can be, but taking the time to participate in this survey will be greatly beneficial to the entire Tor community. To access the survey, please click on the following link: https://cryptpad.fr/form/#/2/form/view/dvbbDORTjeztLzosbOuGVaRheI-FBjFh6xPQ…. The survey will close on 23rd July, so if you are interested in taking part, we kindly encourage you to do so now. Thank you once again for your participation and support. Should you have any questions or require further information, please don't hesitate to reach out to us. Please note that this study has been approved by the UoE Informatics Research Ethics Process, with the project reference number: 775342. Best regards, Meitong Wang & Tariq Elahi The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.

1 0