- tor-relays - lists.torproject.org

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