- tor-relays - lists.torproject.org

new BridgeDB version using rdsys
by meskio 28 Feb '22

28 Feb '22

Hello, I have just deployed a new version of BridgeDB[0]. Now BridgeDB uses rdsys[0] as backend so it has changed how bridges are managed internally, but all the user facing pieces are (almost) the same. The distributors (email, https[1] and moat) hasn't changed and should work as before. If you are a bridge user you should not see any difference. The bridges you are already using should stay working and requesting new bridges should work as before. The move to rdsys implies that all the bridges might have changed their distribution mechanism. If you are bridge operator you might see your bridge having a different distributor mechanism in the coming hours, if you had configured your bridge with the "BridgeDistribution" option your distribution mechanism should not change and stay on what you configured. There are more few more distribution mechanisms now, this is the full list: * https. The web interface of bridgedb[0]. * moat. The API used by Tor Browser to request bridges directly from the settings. * email. Bridges distributed by bridges(a)torproject.org. * telegram. Bridges that will be distributed by the telegram bot @GetBridgesBot. * settings. A new API used to autoconfigure the circumvention mechanism depending on your geolocation. * reserved. Bridges reserved for experiments or future needs. People with bridges assigned to telegram and settings will not see much usage of their bridges yet, as those are projects we are working on but will be soon in use. If you notice any problems with the bridge distribution don't hesitate to open an issue[2] or contact me. [0] https://bridges.torproject.org [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/ [2] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

questions about raspberry pi bridges
by potlatch 22 Feb '22

22 Feb '22

Greetings, I've operated both relays and bridges for more than a decade but I'm new to the raspberry pi. I think it a real possibility for future bridge deployment en mass. I have several questions that I can't seem to work through: 1.) The tor package I get from the repository is 0.4.2.7 (obsolete). I thought it was because the pi machine had raspian for the os. So, I downloaded and installed 32-bit ubuntu server 20.04.3 instead (https://ubuntu.com/downloads/raspberry-pi) It made no difference. I changed to a new SSD to make sure all was virgin. How do I upgrade to current version of Tor for this bridge? 2.) Some of my bridges have (and some do not have) /var/lib/tor/stats folders. I am interested in the 'why' of this and also how I can install that capability on all bridge relays. The stat printout is in units of '8' and I'm sure the Russians, Egyptions, etc. do not use bridges in unit neat units. What am I reading in bridge-stats? 3.) Does Tor project state somewhere in it's docs that it's a terrible idea to give a bridge a nickname such as 'TorCuba'? It should!! potlatch Sent with [ProtonMail](https://protonmail.com/) Secure Email.

4 5

Unexpected classification with my guard relay
by Security GMVSES 22 Feb '22

22 Feb '22

Dear Mr./Mrs., As I really like the Deep Web field, and wanted to know about Tor, I decided to create a guard relay, which is this one: https://metrics.torproject.org/rs.html#details/037F39EF786C0623A059553869C0… I did all the configurations required, but after a couple of weeks, this relay is not considered a guard relay (entry relay) yet. I am contacting you because I don't understand why my relay is not considered as a guard relay (entry relay), since I already have the following flags: Fast, HSDir, Running, Stable, V2Dir, Valid. My configuration is: Nickname securitses ContactInfo securitses(a)gmail.com ORPort 443 ExitRelay 0 ExitPolicy reject *:* SocksPort 9050 AccountingStart day 0:00 AccountingMax 30 GBytes BandwidthRate 301 KBytes BandwidthBurst 350 KBytes ControlPort 9051 HashedControlPassword <Hashed_password> Thank you, Yours sincerely, Javier

4 3

snowflake incoming UDP ports
by Toralf Förster 22 Feb '22

22 Feb '22

I do simply run here ~/devel/go/src/snowflake/proxy/proxy &>>/tmp/snowflake-proxy.log & and was wondering if I have to open special UDP inbound ports ? From the stats snowflake iseems to be working: 2022/02/18 19:29:59 In the last 1h0m0s, there are 13 connections. Traffic Relayed ↑ 192 MB, ↓ 192 MB. 2022/02/18 20:29:59 In the last 1h0m0s, there are 21 connections. Traffic Relayed ↑ 451 MB, ↓ 451 MB. 2022/02/18 21:29:59 In the last 1h0m0s, there are 9 connections. Traffic Relayed ↑ 236 MB, ↓ 236 MB. but b/c I do have a rather restrict inbound firewall rule set I'm wondering about that. -- Toralf

3 4

Reduced exit and not IPv4 exit traffic at all
by yl 21 Feb '22

21 Feb '22

Hello all, how can I used a reduced exit policy and don't allow any IPv4 exit traffic? The following line in the top of all the ExitPolicy lines in torrc seems not to work. ExitPolicy reject 0.0.0.0:* What is the order I needed here, first "reject" and then accept or the other way around? Reduced Exit policy like here: https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReducedExitPolicy Webtropia was a bit unhappy lately when UCEprotect listed the whole /24 for some reason I still don't understand. But then I thought, why not disable IPv4 exit traffic, there is so many IPv6 resources that a IPv6 only Exit should still be fine. Thanks yl

5 8

TorWeather replacement features
by nusenu 20 Feb '22

20 Feb '22

Hi, I'm currently working on a TorWeather replacement (mainly using a byproduct of another project) that should be helpful for relay operators to get notifications about their relay downtimes and other issues. I believe such a service will contribute to a more healthy tor network and better informed operators leading to less relays running on old vulnerable and end-of-life tor versions. For those that did not have the chance to use TorWeather in the past before it died due to lack of a maintainer: It was a simple software as a service for relay operators that allowed them to subscribe for email notifications in case their relay dropped out of consensus (and a few more use-cases). The service will be for the operator of the relay(s). Subscribing and notifications will be aggregated by operators, meaning if multiple relays from a single operator go down at the same time, it will produce a single notification only (instead of one per relay). If a new relay gets added by an operator no additional steps are required to get notification for the newly added relays. You can rate the items below with these levels: (off-list replies are fine as well) 1 = must have 2 = should have 3 = nice to have The system will use the email address in your CIISS email field, which implies it is public. How important are private (non-public) ways to subscribe to notifications for you? (non-public email address) TorWeather used to have an option where the operator was able to specify after what amount of downtime they would get a notification. I would simply go with a single static value: "2 consensus are missing your relays" (2 hours) -> notify. How important are configurable downtime periods to you and what timeframe would you choose? I'm primarily focusing on notifications about "changed to the worse" (i.e. up -> down; ok -> eol). How important are recovery notifications (i.e. down -> up) to you? What would be the next most useful/important notification use-case for you after - relay dropped out of consensus - relay is running a vulnerable/end-of-life tor release - relay lost guard/exit flag The first notification method will be email. How important would be matrix as a second notification method to you? Would you use one or multiple notification methods at the same time? kind regards, nusenu -- https://nusenu.github.io

5 6

torrc, unit files, confusion
by Martin Gebhardt 19 Feb '22

19 Feb '22

Hello together, I've gotten myself stuck in a situation that I can't get out of. The following: I have a working relay. You can find the config for it in the attachment [1]. I want to move parts of the config. So I use %include. I don't do anything else than moving parts of the working config to other files. There are no changes at all. But, tor does not start anymore.In the attachment [2] you can find the config with %include. The folder structure is the following: ├── info.html ├── rc.d │ ├── contact.rc │ ├── family.rc │ └── nickname.rc ├── torrc └── torsocks.conf No matter what I do, I can't get it to enable debug logs when I start tor from the unit file. This is unchanged, but I attached it anyway [3]. Anyway, I start tor as root, then everything works [4]. I have no idea where something should be wrong with the permissions. I have also recursively set the permission of /etc/tor/ to the user debian-tor, but it doesn't help. When I do the following: cat rc.d/* >> torrc && sed -i /include/d torrc && systemctl restart tor Everything works fine again. My system: Linux privacy 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 GNU/Linux Tor version 0.4.6.9. Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.33 as libc. Tor compiled with GCC version 10.2.1 Maybe I'm still too tired to figure it out. But please, can someone give me some advice where to look further? Or at least tell me how to get a debug log when I start tor from the systemd-unit. Then I would surely get further. Thanks for your attention and help. -- Martin

3 3

New relay has a problem - Re-used IP blocked in consensus?
by Olaf Grimm 17 Feb '22

17 Feb '22

Hello Tor community! I have some identical new relays, but only one of them has a problem. My intention was an IPv6 problem, so there ist IPV6 diabled at all. Fingerprint: 3F1AE2170CAD31B5694BD9052A2A29E5793BDC1F IP: 107.189.14.123 Ports open: 22, 80, 9001 Test from outside by scanner: ok UFW firewall open ports set to: 22, 80, 9001 torrc: No IPv6 configuration enabled. The same configuration about all relays. With Nyx I can see built circuits, but the relay does not appear in the metrics, but other relays already show strong traffic. Debian system updates are possible, the HTTP frontpage is displayed at the given IP address, DNS 'unbound' ok because updates are possible. Unbound is set to 127.0.0.1 only. Here some logs from Nyx (copy like displayed): 11:18:41 [INFO] find_my_address(): Unable to find our IP address. 11:18:41 [INFO] address_can_be_used(): Address '::1' is a private IP address. Tor relays that use the default DirAuthorities must have public IP addresses. 11:18:41 [INFO] tor_getaddrinfo(): (Sandbox) getaddrinfo succeeded. 11:18:41 [INFO] get_address_from_interface(): Could not get local interface IP address. 11:18:41 [INFO] get_interface_address6_via_udp_socket_hack(): connect() failed: Cannot assign requested address 11:18:41 [INFO] address_can_be_used(): Address '::' is a private IP address. Tor relays that use the default DirAuthorities must have public IP addresses. 11:18:41 [INFO] get_address_from_config(): No Address option found in configuration. 11:18:39 [INFO] update_consensus_router_descriptor_downloads(): 0 router descriptors downloadable. 0 delayed; 6795 present (0 of those were in old_routers); 0 would_reject; 0 wouldnt_use; 0 in progress. I can not find what is wrong, but I see "::" what is IPv6. In Debian /etc/sysctl.conf IPv6 is disabled. net.ipv6.conf.all.disable_ipv6 = 1 Can you help me? Please check the IP in the consensus. Blocked? Olaf

3 2

Help a newbie
by chuck＠relay-security.org 15 Feb '22

15 Feb '22

I have a problem. This relay was running fine until I changed the nickname. After making the change, I ran “tor --verify-config” just to make sure, and then ran “sudo systemctl restart tor@default” I see it running, but the syslog shows: Feb 14 23:31:46 tor1 tor[592]: Feb 14 23:31:46.000 [info] should_delay_dir_fetches(): Delaying dir fetches (Hibernating or shutting down) Feb 14 23:31:47 tor1 tor[592]: Feb 14 23:31:47.000 [info] should_delay_dir_fetches(): Delaying dir fetches (Hibernating or shutting down) Feb 14 23:31:47 tor1 tor[592]: Feb 14 23:31:47.000 [info] should_delay_dir_fetches(): Delaying dir fetches (Hibernating or shutting down) Feb 14 23:31:48 tor1 tor[592]: Feb 14 23:31:48.000 [info] should_delay_dir_fetches(): Delaying dir fetches (Hibernating or shutting down) and on and on .… What have I done wrong? The fqdn is https://tor1.relay-security.org

1 0

Tor installation from Source
by nikoloskid＠pm.me 11 Feb '22

11 Feb '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, My relay is running on Raspberry OS so the updates are a little late for some packages, so my relay is running on obsolote version 0.3.5.15, I installed Tor from source and tor --version gives me Tor version 0.4.6.10. Tor is running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma N/A, Libzstd N/A and Glibc 2.28 as libc. Tor compiled with GCC version 8.3.0but tor(a)default.service is still running on 0.3.5.15 (I have restarted the service multiple times)... Regards, Daniel Nikoloski Sent with ProtonMail Secure Email. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBzBAEBCAAGBQJiBMpiACEJEAutNI6WgEWAFiEE/jRLdx96gF2z0p05C600 jpaARYCzgQf5AXlzmz1cV38y+/4DMFGMwV74+2acsiAhw8dml1/In34debY1 JgoP6CP+GugKMPAq7JQPvhRF2eVrTYdSN9h0OFrZE3OT45YZWR7uU38MzXd0 NorjBu9lALsE321ocL80igKd+0nXgOofQoWyelaLMRc1YCP8BQLXqv7JLAee 0eZLaHyX8u3OdgyE/ejpbb+7tKzXSkSQZ7vh6e0BEcmQZFXfzEbTuS6jzGQk x8OOYZmF7t4Q1m54NffydyXbQv7hUPYaRFwyMLwdonRl51GFATr+G6vMQqkf QsxxvRQflJ0ANv0cw9oUieMCYXyzrb3oNf9avOucHP477CG6UjwV3A== =m7jC -----END PGP SIGNATURE-----

3 2