- tor-relays - lists.torproject.org

New bridge IN Russia?
by a tor op 06 Mar '22

06 Mar '22

Hi, I am thinking of starting another bridge. In regards to the current situation, is there a real benefit in deploying one within Russia or does that really not matter? A tor op

2 1

rdsys was ignoring BridgeDistribution
by meskio 05 Mar '22

05 Mar '22

As mentioned before[0] BridgeDB now uses rdsys as backend. I just found out that there was a bug in rdsys and the BridgeDistribution configuration was ignored. Private bridges configured with 'BridgeDistribution none' might have being distributed by bridgedb if they were not configured with 'PublishServerDescriptor 0'. Disabling PublishServerDescriptor stops the bridge from sending it's descriptor to the bridge authority, so rdsys doesn't know it exists. Other bridges configured to be used by an specific distributor might have being distributed by a different one. This has being happening from February 28th ~12:00UTC until today March 4 ~12:00UTC. You can search for your hashed fingerprint in the pool assignments during this period if you want to know to what distributor was your bridge assigned to: https://metrics.torproject.org/collector/recent/bridge-pool-assignments/ Only bridges assigned to moat, email or https might have being distributed, as telegram, settings and reserved bridges are not distributed at the moment. The metrics relay search[1] will take some time to display the new assignments. I'm sorry for the situation. [0] https://lists.torproject.org/pipermail/tor-relays/2022-February/020365.html [1] https://metrics.torproject.org/rs.html -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

2 2

Odd network activity
by awffelwaffels 04 Mar '22

04 Mar '22

I see on every exit node I check on the metrics page, a massive bump in bandwidth used without a change in exit probability. Is this perhaps an attacker squeezing the bandwidth of the network so people are more likely to use their malicious nodes?

5 9

Tor Relay Meetup #Fosdem Notes
by gus 04 Mar '22

04 Mar '22

Hello, Last Saturday, a group of 30 - 40 operators joined the Tor Relay Operator meetup. Thank you all for joining the event! Our next online meetup will happen on March 5th, 2000 UTC. Gus ## Fosdem Meetup Notes * Bridges campaign update: "When we started the campaign on November 17, 2021, the Tor network had approximately 1,200 running bridges. The Tor network now has 2470 running bridges, i.e., the number of Tor bridges has almost doubled!" https://blog.torproject.org/wrapping-up-bridges-campaign/ * Gamification project update: - Survey Insights for Tor Relay Operators: https://gitlab.torproject.org/tpo/community/relays/-/issues/31 * EOL 0.3.5 removal: "Tor 0.3.5.x is unsupported beginning tomorrow, 02/01/2022. We should contact the relay operators still on it where possible to get them upgraded and then after a couple of weeks (4 maybe) remove the remaining relays from the network (see: #56 (closed) for previous work in that area)." https://gitlab.torproject.org/tpo/network-health/team/-/issues/171 * New texas relay operator group? are there others? CCCS? "We are just a small provider trying to help out the community. We believe that privacy is a fundamental right for everyone. We hope to make the internet a better place by deploying privacy based tools for everyone to use.Checkout stormycloud.org for additional information." * torservers.net reanimation continues. New website (feedback welcome) is online: https://torservers.net/ Thanks Leibi, qbi and others for the work! ### Q&A session * Who runs Tor relays today? Do we need more transparency? (no mic) * Yes, we need more transparency. Gus describes a proposed "community mapping" exercise where we learn who has links / connections to other relays. * Best providers for exit nodes? * For exits, I can recommend terrahost.no They are based in Norway, have unmetered offers and allow exits with a reduced policy in their Terms of Service * See: https://community.torproject.org/relay/community-resources/good-bad-isps/ * Would recommend avoiding hetzner, ovh, frantech, buyvm, there are too many relays there already. * Are there any plans for AS-aware tor circuit creation? (Kristian - lokodlare) Not currently -- the AS-aware Tor designs (like Raptor and following) are cool but have a bunch of big open questions and unresolved potential vulnerabilities too. So, a great research area, but comes with too many security tradeoffs currently. For a cool recent attack paper in the area, check out: https://www.freehaven.net/anonbib/#tempest-pets2018 * Are there plans on improving tor prometheus metrics? (more metrics: uptime, bandwidth, ...) It turns out the DNS metrics we had were buggy and not so useful. So there is some work to improve the accuracy / usefulness of the current metrics. https://gitlab.torproject.org/tpo/network-health/team/-/issues/175 * is C tor dead in terms of new features like this? (all dev capacity goes into rust only?) C tor is going to be deprecated over time, but the Arti roadmap involves not getting to relays for years, so there will be an interim period where we're wishing we could deprecate the C-Tor relay side yet there is no Arti relay side replacement yet. * will arti implement the control spec (compatibility with stem) no, at least not as it currently is. arti wants to be a library you can link in * Is the GeoIP location implementation for relays based on ASNs or actual country-based IP blocks. One relay operator's server is located in Japan but the AS seems to be American so the location is listed as the US. We switched from Maxmind GeoIP to IPFire in the past year. * Are there instructions for how people can report bugs to IPFire? Yes, look at https://forum.torproject.net/t/tor-relay-search-showing-location-of-some-re… We had an example where a relay operator requested a change from IPFire, and it seems to have gone surprisingly smoothly and easily. * MCH: There will be a real in-person hacker con this summer, MCH https://mch2022.org/, with at least one Tor relay operator known attending and at least one Tor developer known attending. * Is running a Snowflake proxy as useful as a (obfs4) bridge? If you have a static IP address, maybe the obfs4 bridge is smarter? Since the Snowflake model involves having many transient proxies. * Are there timelines for IPv6 only Tor or Bridge families? tor 0.4.8.x will get MyFamily support for bridges according to Nick (C tor) https://gitweb.torproject.org/torspec.git/tree/proposals/321-happy-families… * Would it be a good idea to run a web-server on the same computer as a tor bridge? Because it would introduce collateral damage? Maybe yes in theory, but in practice these days no. Russia and China block bridges by IP address in a quite automated way and they don't seem to care what else is on that computer. Mostly these censors find bridges not by looking at network traffic, but by pretending to be users showing up to bridges.torproject.org. So the censors who try to build blocklists aren't even looking much at the addresses they block. * will arti implement the control spec (compatibility with stem) * Answer: I think I've heard that it probably won't, or at least not entirely * Is it bad to have too many exit relays in one country? And how many is too many? * Norway and the US and DE seems to be quite saturated already with exit relays: NO - 37, 481 MiB/s Tor metrics numbers US - 536, 4898 MiB/s DE - 329, 8206 MiB/s See: https://metrics.torproject.org/rs.html#aggregate/cc https://nusenu.github.io/OrNetStats/ * Getting fast relays in Japan is challenging because of how we measure bandwidth weights. Is sbws moving forward? How about a newer bwauth design to make use of better geo-relay-distribution? * Will rust tor solve the multiple CPU core issue (no more multiple tor instances required on a multi core machine)? Answer: Hopefully yes, arti is multithreaded, but not as fast as C tor yet * Is stem unmaintained? Yes. * Damian no longer working on stem? I believe that Damian is no longer actively developing stem, but that he is maintaining it, in the sense that if you submit a patch he might take it, or if you submit a security issue he'll probably look at it. * How far away are we from rust tor support relays? will that also be called arti or is arti just the tor client functionality? * How far away are we from a first tor browser alpha using arti? Arti roadmap says it should be "ready for production use" in september 2022, but that's without anti-censorship stuff and onion service support. * Russia has blocked Tor relays? Tor is now pretty essential for Russians. Is speed important there? Lower latency is really useful when you're using Tor. Compare Russia to China -- China grows its internal network capacity, but not its external network capacity, and over time it becomes more fun to use Chinese services in China, and less fun to use external services in China. Will Russia go that route? We'll see. Hopefully not for a while. * How to get more Tor advocacy in each of our local areas? Seems like you read about bad people using the internet but not enough about why Tor is important. * Who runs bw authorities? How could we get one in asia? They are the services that pick weights for relays in the consensus, so they are trusted in a similar way to how directory authorities are trusted. So, right now they're run either *by* the dir auth operators, or there's a 1:1 trust relationship from dir auth operator to bwauth operator. Putting a bwauth in Asia would probably just measure all the relays as slow. And part of that is because of our sub-optimal congestion control design in Tor right now, which Mike is working on. It seems wise to wait until Mike has his fix in place, and then we can understand how much of the "geographic diversity is slow" problemwe've fixed, and how much of it remains. * SysAdmin 101 workshop Gman discusses a proposed idea on teaching relay operators about how to sysadmin properly, how to make decisions about bare metal vs VM, how to get time synchronization working right, all of the things that relay operators need better intuition about. General consensus is yes this is a good idea and could benefit a lot of people. Gman requests suggestions for most important material and topics. https://gitlab.torproject.org/tpo/community/relays/-/issues/36 * What about raising the fast relay flag threshold? The reasoning being that if you remove the really slow relays from the network, then even though there are fewer relays, average circuit performance gets better? This is actually just one of dozens of ideas we have for improving performance, and the plan is to use Mike's framework for doing a proper experiment for each idea, and measuring whether it actually helps: I think gitlab link is https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues There is a great wiki page too, listing e.g. what network characteristics to measure. Start here: https://gitlab.torproject.org/legacy/trac/-/wikis/org/roadmaps/CoreTor/Perf… and here: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Sponsor61/P… Idea for an agenda topic for next time: Mike's network-wide performance experiments, how to do experiments safely and productively on the live Tor network. -- The Tor Project Community Team Lead

3 3

Your opinion about tor-node.org
by Martin Gebhardt 03 Mar '22

03 Mar '22

Hello all, I don't know who of you is familiar with this, I just came across it a few weeks ago. It's about tor-node.org. It is probably a person who collects funds for the operation of Tor infrastructure. Nothing wrong with that and I applaud that. What you might find objectionable, but I don't, are the sponsors.They are marketplaces that make their money from drug dealing and other illegal sales. I don't mind that, anything is better than buying your addictive substance from windy guys at the train station. But what bothers me is the transparency. I also believe that using Tor is an act of anonymity. But running Tor infrastructure is an act of transparency. I am very interested in knowing who is working on our project. Unfortunately, the operator can't come forward here either, because then his anonymity towards the marketplace scene would be over. On the one hand, the operator justifiably wants to remain anonymous. Just to protect his sponsors. On the other hand, however, this leads to the fact that he can not reveal himself as an relay owner within the operators. The operator can also not disclose to his sponsors what happens with their money. Because then the sponsors would know which relays are operated and then it is over with the anonymity. Without wanting to imply it, I think that this can also simply be a fraud against the sponsors. I wouldn't care about that either. But I do not think that this is the case and assume that relays are operated. What do you think about it? For me, it's a breach of the principle of transparency, which I'm sure most of you here agree with. I would like to emphasize that I welcome every supporter of the network and I am glad about every single relay. But do we as a community welcome this kind of relay operators? Feel free to express your opinion. -- Martin

5 8

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

Legal bases
by Martin Gebhardt 10 Feb '22

10 Feb '22

Hello all, I would like to read about experiences with local laws of various countries. So far I run my exits in Austria, Germany and the Netherlands. I have found a provider for me that also covers the following countries and has no problem with Tor exits: - Poland - Australia - Singapore - France My goal is to have a unified website for each country, where you can find links to official websites of the countries with "traffic passing " laws. For AT, DE and NL these are known to me. For the other countries not. Now before I start searching and messing around with translators, I hope someone here has experience in one or more of these countries and can provide with paragraphs. I am grateful for any hint. -- Martin

1 0

Re: [tor-relays] snowflake vs bridges (vs node)
by Fran 08 Feb '22

08 Feb '22

Thanks meskio, this helped a lot to clarify things. So I thought of trying to run a bride and a snowflakeproxy on one VM with individual IP addressing in v4 and v6 for each by adding secondary addresses to to the WAN interface. But after compiling the go binary I fail to find out how to tell snowflake which IP to bind to/use. For the bridge this can be achieved with: Address <IPv4> Address <IPv6> OutboundBindAddress <IPv4> OutboundBindAddress <IPv6> (and maybe to be save also set OutboundBindAddressPT, OutboundBindAddressExit and OutboundBindAddressOR) But for snowflake I'm missing the options: Usage of ./proxy: -broker string broker URL (default "https://snowflake-broker.torproject.net/") -capacity uint maximum concurrent clients -keep-local-addresses keep local LAN address ICE candidates -log string log filename -nat-retest-interval duration the time interval in second before NAT type is retested, 0s disables retest. Valid time units are "s", "m", "h". (default 24h0m0s) -relay string websocket relay URL (default "wss://snowflake.bamsoftware.com/") -stun string broker URL (default "stun:stun.stunprotocol.org:3478") -summary-interval duration the time interval to output summary, 0s disables retest. Valid time units are "s", "m", "h". (default 1h0m0s) -unsafe-logging prevent logs from being scrubbed -verbose increase log verbosity Could be solved with VRFs/namespaces but would involve bridging, veths...too snowflaky for me (same goes for containers). So I guess I'll just keep the bridges and make then relays one day. Thanks for all who helped! best fran On 2/7/22 11:12, meskio wrote > Yes, there are many differencies. snowflake does make the traffic look like > webrtc (like a video conference) and obfs4 makes the traffic look like random > noise. Also the clients use different mechanisms to discover the relays. > > If you run both in the same IP address and the censor has a way to discover one > but not the other both of them will be blocked at once. So you are making it > easier for the censor to discover them and block them. That is why we don't want > people to run both in the same IP address.

2 1

cases where relay overload can be a false positive
by s7r 07 Feb '22

07 Feb '22

Hello, One of my relays (guard, not exit) started to report being overloaded since once week ago for the first time in its life. The consensus weight and advertised bandwidth are proper as per what they should be, considering the relay's configuration. More than this, they have not changed for years. So, I started to look at it more closely. Apparently the overload is triggered at 5-6 days by flooding it with circuit creation requests. All I can see in tor.log is: [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [68382 similar message(s) suppressed in last 482700 seconds] [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [7882 similar message(s) suppressed in last 60 seconds] This message is logged like 4-5 or 6 time as 1 minute (60 sec) difference between each warn entry. After that, the relay is back to normal. So it feels like it is being probed or something like this. CPU usage is at 65%, RAM is at under 45%, SSD no problem, bandwidth no problem. Metrics port says: tor_relay_load_tcp_exhaustion_total 0 tor_relay_load_onionskins_total{type="tap",action="processed"} 52073 tor_relay_load_onionskins_total{type="tap",action="dropped"} 0 tor_relay_load_onionskins_total{type="fast",action="processed"} 0 tor_relay_load_onionskins_total{type="fast",action="dropped"} 0 tor_relay_load_onionskins_total{type="ntor",action="processed"} 8069522 tor_relay_load_onionskins_total{type="ntor",action="dropped"} 273275 So if we account the dropped ntor circuits with the processed ntor circuits we end up with a reasonable % (it's >8 million vs <300k). So the question here is: does the computed consensus weight of a relay change if that relay keeps sending reports to directory authorities that it is being overloaded? If yes, could this be triggered by an attacker, in order to arbitrary decrease a relay's consensus weight even when it's not really overloaded (to maybe increase the consensus weights of other malicious relays that we don't know about)? Also, as a side note, I think that if the dropped/processed ratio is not over 15% or 20% a relay should not consider itself overloaded. Would this be a good idea? Sending to tor-relays@ for now, if some of you think of this in any way we can open a thread about it on tor-dev@ - please let me know if I should do this.

3 5

Genereal queations about MyFamily
by Martin Gebhardt 07 Feb '22

07 Feb '22

Hello, I am running some servers in the Tor infrastructure for research reasons and my own (mainly political) interest. I have a few questions, the answer to which would help me a lot at the moment. 1. can someone explain to me how the fingerprint of a Family is created? For example, I have 7 exit relays in a Family, and can't remember how that came about. 1. 2. to simplify the torrc, would it not be advantageous to enter in "MyFamily" not all fingerprints, but only that of the Family as such? Are there already suggestions for this with the developers? If not, which Git would be the most suitable to place my suggestion? I know, then everyone could "join" a family, since another node does not explicitly also include the one in the config. But there will be a solution for that. Like with AROI from nusenu. I explore various possibilities to deanonymize. My motives are solely dedicated to the Tor project. I have configured a bridge and I know that it is also possible to restrict exits. For example via the country code. I have also done that successfully, but: 2. 1. I don't manage to configure a bridge _and_ a fixed exit. 2. 2. also here I would welcome a feature to specify the fingerprint of a family as forced exits instead of single fingerprints or countrycodes. Also here the question like in 1.2, where could I place this then best. All this does not necessarily provide an advantage in anonymization, but it makes research much easier. And before someone says that i don't need that... there is a lot that i don't need and that doesn't serve the purpose of a software, you are not forced to configure it let alone recommend it. I'm just talking about possibilities that should facilitate the research. -- Martin

3 4

snowflake vs bridges (vs node)
by Fran 07 Feb '22

07 Feb '22

Hey, I just saw, that it's possible to run snowflake[1] not only as browser plugin, but also standalone. So I am wondering what makes more sense, run a bridge with obsf4 or run a snowflake instance instead of a bridge. Or would it even make sense to install both on one server? And generally, what's more needed atm: bridge, non-exit, exit or snowflake? Thanks! fran [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

5 6

ExitNodes Directive Evaluated Dynamicly or Bootstrap Only?
by Gary C. New 06 Feb '22

06 Feb '22

All: Is the ExitNodes Directive evaluated Dynamicly or only during Bootstrap? What happens if an exit in the ExitNodes list is down when selected? Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged)

1 0

Outdated GeoIP DB
by Martin Gebhardt (Die LINKE.) 06 Feb '22

06 Feb '22

Hi, in the past I had already written with someone about it. At that time the entries were not up to date. There was a Gitlab issue about this, but I can't find it now. Anyway, the data is not up to date again. Example: https://apps.db.ripe.net/db-web-ui/query?searchtext=89.58.17.76 vs https://metrics.torproject.org/rs.html#details/6A0A9C3B3381C89CCB85C64BBCF6… The IP address is currently located in Austria. But in the metrics Germany is displayed. This is a "correct" but outdated information. Since I don't know if this can have any effects on the routing, which I don't assume, but is theoretically possible, I just want to target it again.

6 6

Relay operators meetup @ FOSDEM
by Stefan Leibfarth 04 Feb '22

04 Feb '22

Greetings relay operators, the next Tor relay operators meetup will be online @ FOSDEM. Date: 2022-02-05 Time: 1500 UTC Room: https://lecture.senfcall.de/rin-2tx-xcy-g5r No need for a registration or anything else, just use the room-link above. There will be a agenda, but everyone is free to bring up additional questions or topics at the meeting itself. Looking forward to meeting you Leibi [0] https://fosdem.org/2022/fringe/

3 2

Recommended IPv6 Configuration
by t.duellmann+torrelays＠gmail.com 03 Feb '22

03 Feb '22

Dear list, I read here [1] that IPv6 is on the rise and support for it is growing. Are there any recommendations or best-practices how to configure a Tor relay with IPv6? Alternatively, could anybody who got it set up already, post their experiences and maybe even the relevant parts of their torrc? Thanks! [1] https://blog.torproject.org/state-of-ipv6-support-tor-network/

3 2

Exit relays abused to attack Google services
by UDN Tor 02 Feb '22

02 Feb '22

Google is now sending abuse reports complaining of DDoS attacks against their services. While they believe the IPs are participating in a botnet, it is clear that they are Tor exit relays. I don't know why they are sending us the report after the attacks have ended. Besides, since Google services are unusable over Tor, this should not have caused them much damage. I suspect the attacker is trying to get relays shut down by triggering Google reports that would scare off the ISPs. If you are an ISP and you have received the same report, please let me know. I'd like to know if this was global or if we've been "selected". > From: ddos-reports(a)google.com > To: abuse(a)urdn.com.ua > Subject: [#zMto] DDoS from your IPs to Google from 2022-01-28 to > 2022-01-31 > Date: Tue, 01 Feb 2022 20:22:42 +0000 > > We observed IPs under your control participating in DDoS attacks > targeting Google services, including a prolonged DDoS attack from > January 28-31 against the Google Search Console. > > The attacks were Layer 7 / HTTP request floods. Your participating > IPs are listed below, along with the stop time in UTC and targeted > Google IPs. We request that you enforce your Acceptable Use Policy > against these customers. > > +-----------------+-----------------+----------+---------------------+ > | Source | Destination | DestPort | Time_UTC | > +-----------------+-----------------+----------+---------------------+ > | 193.218.118.62 | 142.250.180.227 | 443 | 2022-01-31 15:55:01 | > | 193.218.118.90 | 142.250.180.195 | 443 | 2022-01-31 15:53:28 | > | 193.218.118.100 | 172.217.19.99 | 443 | 2022-01-31 14:43:09 | > | 193.218.118.101 | 142.250.180.227 | 443 | 2022-01-31 17:32:54 | > | 193.218.118.125 | 142.250.180.227 | 443 | 2022-01-31 15:55:28 | > | 193.218.118.145 | 142.250.180.195 | 443 | 2022-01-31 15:55:30 | > | 193.218.118.147 | 142.251.39.35 | 443 | 2022-01-31 15:41:36 | > | 193.218.118.155 | 142.250.180.195 | 443 | 2022-01-31 13:45:43 | > | 193.218.118.156 | 142.250.180.227 | 443 | 2022-01-31 15:57:52 | > | 193.218.118.158 | 142.250.180.227 | 443 | 2022-01-31 18:41:34 | > | 193.218.118.167 | 142.250.201.195 | 443 | 2022-01-31 15:56:53 | > | 193.218.118.182 | 142.251.39.3 | 443 | 2022-01-31 17:31:57 | > | 193.218.118.183 | 142.250.180.227 | 443 | 2022-01-31 17:42:40 | > | 193.218.118.231 | 142.250.180.227 | 443 | 2022-01-31 17:43:08 | > +-----------------+-----------------+----------+---------------------+ > > Note we believe some of these IPs are part of the Meris or Dvinis > botnets. If you are a residential Internet service provider, it is > possible that your customers' routers themselves have been > compromised. You should research the Meris botnet and take > appropriate actions to have them secure their CPE (customer-premises > equipment). > > -- > Security Reliability Engineering :: Google :: AS15169

4 3