- tor-relays - lists.torproject.org

Re: [tor-relays] Why MyFamily?
by [REDACTED] 23 Feb '20

23 Feb '20

Hi nusenu Am Fr., 21. Feb. 2020 um 22:24 Uhr schrieb nusenu <nusenu-lists(a)riseup.net>: > Hi [REDACTED], > > > Last week i got an email with a warning that some of my relays are > > missing the correct MyFamily setup and that i am a risk to do > > end-to-end correlation attacks together with a list of all relays i > > operate plus one relay which uses the same name than i use but is not > > operated by me. > > the email [REDACTED] is referring to for the interested readers: [1] > > > I already knew that not all of my relays have a correct MyFamily setup > > because as long as i am not sure if they will stay i usually dont > > include them in MyFamily because it is a pain to edit every torrc > > Yes, manually managing MyFamily is a pain with that many relays. > It is best to automate it so you don't have to worry about it > no matter how long your relays might run. > > It is also relevant to note that we are not talking about fresh relays > (born days or weeks ago) but >6 months. > I think the relay you are talking about is the relay in Yekaterinburg. This relay is not listed as with no MyFamily in the first email but after receiving the first email i decided that i am okay with the newer hoster more than the older hoster so i included the newer one in MyFamily and excluded the older one and will probably let it expire so the relays mentioned with no MyFamily setup in the first and the ones in the second email should be slightly different. But thats not important anyway. I usually wait at least one billing period. Some of my relays are paid for three years in advance which means there might be cases where a relay will be in a state of unknown for three years till i know if they will stay. > > A few days later i got a message that some of my relays will soon get > > rejected because i did not responded to the previous email. > > A more correct version is: some relays were proposed for removal on the > bad-relays@ list > should there not be any reaction by the operator [2]. > > That is something different than informing an operator about an upcoming > removal since > everybody can propose removals and only dir auths can actually vote for > the removal. > Understood. > [2] > For the readers on this list, this is the second mentioned email: > > I'm proposing the removal of the first 5 entries in the following table > (end-to-end correlation risk) > > should there not be any reaction to this email from the operator. > > > > A previous email from 2020-02-15 did not result in a reply so far. > > > > > +---------------------+--------+----------------------+------------------+-------------------+-----------------+---------------------------------------------------+------------------------------------------+ > > | first_seen | member | contact | nickname > | tor_version | IP | as_name > | fingerprint | > > > +---------------------+--------+----------------------+------------------+-------------------+-----------------+---------------------------------------------------+------------------------------------------+ > > | 2020-02-01 18:00:00 | 1 | NULL | angeltest33 > | 0.4.2.6 | 139.99.238.17 | OVH SAS > | 4BF3D299BC500C350868F078749291C766C7AA6F | > > | 2020-01-11 16:00:00 | 1 | NULL | angeltest5test > | 0.4.2.6 | 51.38.147.96 | OVH SAS > | 951307BA74E44A9C9C208B2F134CDA2409944075 | > > | 2019-08-06 11:00:00 | 1 | NULL | angeltest27 > | 0.4.2.6 | 185.173.177.153 | GalaxyStar LLC > | 95C8B9418E74F3FF80E5C3D3AF7F03156FFBBFBE | > > | 2019-08-31 09:00:00 | 1 | NULL | angeltest9 > | 0.2.9.14 | 104.244.76.190 | FranTech Solutions > | F1D5C0F5157D9B24014BE8C7A1D878AEA6843B42 | > > | 2019-11-21 12:00:00 | 1 | NULL | angeltest26test > | 0.4.2.6 | 91.243.50.239 | Petersburg Internet Network ltd. > | F51A927E34662D6005393F2327C870FB0D0D7FE0 | > > > > > - The bad-relays team expect an answer to their emails even if they do > > not tell you that in the first email and rather send you a second > > email that they will soon reject your relays if you dont answer them. > > I think you are confusing the "bad-relays team" with subscribers or people > sending emails to the bad-relays@ list. > If in doubt require the sender to have a @torproject.org address > (unfortunately there is no actual sender address for the bad-relays team > since it is just a mailing list) > The senders name was "tor-bad-relays(a)riseup.net" which looked official to me. Then Georg Koppen "validated" the second email. For the next time i know that i only need to respond to valid emails. > > So for what reason do i set the MyFamily option beside making a Hidden > > Service Guard discovery attack more easy? > > > - risk reduction for tor users > MyFamily declarations allow the tor client software to automatically > detect relay families when creating circuits to > avoid using multiple relays from the same operator in a single circuit. > This should not matter if the operator is not malicious and like i already said an malicious operator will not use the same contact info or relay name. - reducing the risk for tor users that might become victims if some > operator gets compromized (with all its relays) > This is a reason i can understand. Not sure how much that would really help in practice but i can understand it. - transparency > Every relay operator should declare their relay group to allow everybody > to measure their network fraction (Sybil detection). > Should... But i understand this one too. But as long as my family is still a small one with only one exit compared to others i am not a Sybil attack risk and even if i would would i get any special treatment then? - risk reduction for relay operators > MyFamily also provides risk reduction for operators since they are less > valuable as an attack target > if they can not technically be used for e2e correlation attacks > I think this is similar to your first point but i think that should be the operators choice if he want to take steps against this case. - allow the identification of "false-friends" and actual malicious relays > By setting MyFamily you make it easier to detect relays that claim to be > you > since MyFamily requires mutual configuration malicious entities can not > add their relays to your MyFamily. > > This is what happened in your case (which was a mixture of > misconfiguration and actual "false-friends"). Talking about that particular possibly malicious FranTech relay the operator and me set their MyFamily correctly. I did not included it in my family because i am not the operator and he did not tried to include it in my family so relying on MyFamily was useless anyway. I knew about that relay for some while already because i first thought i had accidentially made one of my relays an exit but decided to not report it because relay names are free to choose. Thats the reason why i was so mad about the fact that someone assume this particular malicious relay is operated by me because what the other possibly malicious operator tried to achieve (to look like me) was exactly what happened. I think MyFamily greatly fails in trying to solve a problem and is making life for honest operators more difficult but not for mailicious operators. > > If you are really interested into the MyFamily topic you can find a few > tickets on trac.torproject.org about it > (including arguments against it). > I will look into it. > > > > [1]: > > Hello, > > > > This email wants to make you aware that you are probably putting tor > users > > at risk by not properly setting MyFamily on your tor relays. > > > > If the relays using your contactInfo are not actually yours > > please send an email to bad-relays(a)lists.torproject.org > > so they can be removed from the network for impersonating your > contactInfo. > > > > > https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#torrpi1405g… > > > > Thanks for taking care of this. > > > > > +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+ > > | first_seen | exit | nickname | member | contact > | tor_version | IP | fingerprint > | > > > +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+ > > | 2018-08-28 21:00:00 | 0 | angeltest2 | 27 | > [REDACTED] | 0.4.4.0-alpha-dev | 5.39.60.243 | > 3B07C500AC17E7B5A1EE616613E104A094AB87F3 | > > | 2018-09-05 17:00:00 | 0 | angeltest7 | 27 | > [REDACTED] | 0.4.2.6 | 37.252.187.111 | > EE4AF632058F0734C1426B1AD689F47445CA2056 | > > | 2018-09-05 20:00:00 | 0 | angeltest8 | 27 | > [REDACTED] | 0.4.2.6 | 185.112.82.50 | > 7AAF5597B18D82CC90CA95FB7976A1CEA4A32E06 | > > | 2018-09-07 23:00:00 | 0 | angeltest9 | 27 | > [REDACTED] | 0.4.2.6 | 92.38.163.21 | > 9288B75B5FF8861EFF32A6BE8825CC38A4F9F8C2 | > > | 2018-09-27 00:00:00 | 0 | angeltest11 | 27 | > [REDACTED] | 0.4.2.6 | 213.183.60.21 | > 39F91959416763AFD34DBEEC05474411B964B2DC | > > | 2018-09-27 19:00:00 | 0 | angeltest12 | 27 | > [REDACTED] | 0.4.2.6 | 91.201.65.91 | > 57C6DF5B93E54EB9C8DB90029D9E9A1111BD34D2 | > > | 2018-12-15 00:00:00 | 0 | angeltest14 | 27 | > [REDACTED] | 0.4.2.6 | 195.123.245.141 | > 465D17C6FC297E3857B5C6F152006A1E212944EA | > > | 2019-01-10 00:00:00 | 0 | angeltest18 | 27 | > [REDACTED] | 0.4.2.6 | 94.140.125.122 | > B517198B86B3859C307857C59F6660A281FC8B47 | > > | 2019-01-10 22:00:00 | 0 | angeltest19 | 27 | > [REDACTED] | 0.4.2.6 | 185.246.152.22 | > A86EC24F5B8B964F67AC7C27CE92842025983274 | > > | 2019-02-26 10:00:00 | 0 | angeltest20 | 27 | > [REDACTED] | 0.4.2.6 | 178.17.170.103 | > ADE6AB2BFBD7A5780B321DC33BBACCD0D777C94D | > > | 2019-04-26 12:00:00 | 0 | angeltest23 | 27 | > [REDACTED] | 0.4.2.6 | 81.169.235.154 | > EFA2E7B073AA4CE2DAF7160F23C90DB805948F4A | > > | 2019-05-29 07:00:00 | 0 | angeltest26 | 27 | > [REDACTED] | 0.4.2.6 | 89.223.100.121 | > 40108FDFA40EDB013F7291F3B4DA3D412ED3A5EF | > > | 2019-08-06 11:00:00 | 0 | angeltest27 | 27 | > [REDACTED] | 0.4.2.6 | 185.173.177.153 | > 95C8B9418E74F3FF80E5C3D3AF7F03156FFBBFBE | > > | 2019-08-13 12:00:00 | 0 | angeltest6 | 27 | > [REDACTED] | 0.4.2.6 | 185.61.149.67 | > 295F1BD8995A12ECC77E050CCF6EC641572739E9 | > > | 2019-08-19 04:00:00 | 0 | angeltest28 | 27 | > [REDACTED] | 0.4.2.6 | 31.207.89.49 | > 1A7A2516A961F2838F7F94786A8811BE82F9CFFE | > > | 2019-09-19 14:00:00 | 0 | angeltest3 | 27 | > [REDACTED] | 0.4.2.6 | 62.141.38.69 | > FF9FC6D130FA26AE3AE8B23688691DC419F0F22E | > > | 2019-10-02 19:00:00 | 0 | angeltest10 | 27 | > [REDACTED] | 0.4.2.6 | 178.254.20.159 | > C1939D36649DE98A202429631D8EFC70128D5F5F | > > | 2019-11-01 05:00:00 | 0 | angeltest5 | 27 | > [REDACTED] | 0.4.2.6 | 51.38.134.104 | > 39C6F833D4B09524770D3655DF825A11213CA0A9 | > > | 2019-11-01 08:00:00 | 0 | angeltest27test | 1 | > [REDACTED] | 0.4.2.6 | 92.223.109.71 | > 1323D34C2FA4AE0EC4EEA9853F3464693EF428E7 | > > | 2019-11-02 14:00:00 | 0 | angeltest17 | 27 | > [REDACTED] | 0.4.2.6 | 5.34.183.29 | > F8AA8D8CCBA0C5F2836DE6315CDFA6E4A31A0890 | > > | 2019-11-05 14:00:00 | 0 | angeltest13 | 27 | > [REDACTED] | 0.4.2.6 | 185.225.17.173 | > A4CC39184AD287D72C2247738835811C7A7ECB8E | > > | 2019-11-21 12:00:00 | 0 | angeltest26test | 1 | > [REDACTED] | 0.4.2.6 | 91.243.50.239 | > F51A927E34662D6005393F2327C870FB0D0D7FE0 | > > | 2019-12-11 22:00:00 | 0 | angeltest29 | 27 | > [REDACTED] | 0.4.2.6 | 87.106.152.102 | > 73283C4DEBC01D3E4A5FD1BB1F2B50D927379F59 | > > | 2019-12-20 04:00:00 | 0 | angeltest24 | 27 | > [REDACTED] | 0.4.2.6 | 2.56.241.243 | > 401A66747713038CEEF6ED28C8AFEB70570EEBCC | > > | 2019-12-20 06:00:00 | 0 | angeltest25 | 27 | > [REDACTED] | 0.4.2.6 | 185.118.164.41 | > C9BC841E180B35F229FD47664F84CF8A8ADB3F68 | > > | 2019-12-24 16:00:00 | 0 | angeltest30 | 27 | > [REDACTED] | 0.4.2.6 | 185.4.135.157 | > B93503D458D9FE97DE5C12D211082871D08F1284 | > > | 2020-01-11 16:00:00 | 0 | angeltest5test | 1 | > [REDACTED] | 0.4.2.6 | 51.38.147.96 | > 951307BA74E44A9C9C208B2F134CDA2409944075 | > > | 2020-01-12 17:00:00 | 0 | angeltest31 | 27 | > [REDACTED] | 0.4.2.6 | 185.101.35.219 | > 2F8B9500DC98C13FD28CC51E47D3416DE423ED78 | > > | 2020-01-14 15:00:00 | 0 | angeltest32 | 27 | > [REDACTED] | 0.4.2.6 | 185.99.2.178 | > 12B1A5769D38FF47CF68C2235E1BDA315DF400F2 | > > | 2020-01-23 04:00:00 | 0 | angeltest16 | 27 | > [REDACTED] | 0.4.4.0-alpha-dev | 195.123.238.164 | > D5812BAB52820A4D448E5F16EE363A0F4CEEF691 | > > | 2020-02-01 18:00:00 | 0 | angeltest33 | 1 | > [REDACTED] | 0.4.2.6 | 139.99.238.17 | > 4BF3D299BC500C350868F078749291C766C7AA6F | > > | 2020-02-11 14:00:00 | 1 | angeltestwindows | 1 | > [REDACTED] | 0.4.2.5 | 91.132.147.168 | > DC81AA3B1D51566DBF27BFA562E4047AEB1C52DA | > > > +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+ > > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

5 10

New relay on dynamic IP address
by Mario Costa 21 Feb '20

21 Feb '20

Hello, I started a new relay at home. I was really surprised to see it gain a Guard flag in about a week since it first came online. My first relay (on a VPS) became a Guard well over a month after I set it up. How can I assess what was different this time? Also, I’m wondering what will happen when the dynamic IP changes. Sooner or later I’ll have a power outage or restart the modem. Last time my IP changed it happened overnight for no evident reason. Will this relay lose its flags? Is a really with a dynamic IP address useful at all? Cheers, -m

7 10

100% CPU load on Windows Server 2019
by [REDACTED] 21 Feb '20

21 Feb '20

Hi, for diversity purposes and curiosity i decided to choose Windows Server 2019 together with TheOnionPack for my first exit relay. But before it even started to process any user traffic the CPU from time to time gets maxed out for several minutes what makes it ugly to operate a relay on Windows. Looks like its this one: https://trac.torproject.org/projects/tor/ticket/24857 Will there be a fix soon or should i rather switch to Linux? Greetz

3 5

unbound statistics interpretation
by Toralf Förster 19 Feb '20

19 Feb '20

Hi, at a system shutdown unbound writes the stats in the syslog. Looking at the stats (pls see below) at a fast relay with 5 days uptime let me wonder about the huge resolving times above the 4 second limit. Especially I do wonder if there's a parameter to tell unbound to stop a resolving attempt -say- after a minute or so? I'd appreciate stats of other relay operators. Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: service stopped (unbound 1.9.6). Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: server stats for thread 0: 1309396 queries, 97671 answers from cache, 1211725 recursions, 0 prefetch, 0 rejected by ip ratelimiting Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: server stats for thread 0: requestlist max 395 avg 7.96712 exceeded 0 jostled 0 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: average recursion processing time 1.439270 sec Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: histogram of recursion processing times Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: [25%]=0.0159959 median[50%]=0.0373616 [75%]=0.103885 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: lower(secs) upper(secs) recursions Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.000000 0.000001 29362 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.000128 0.000256 3 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.000256 0.000512 107 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.000512 0.001024 719 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.001024 0.002048 277 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.002048 0.004096 847 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.004096 0.008192 109419 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.008192 0.016384 170260 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.016384 0.032768 258052 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.032768 0.065536 262585 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.065536 0.131072 131851 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.131072 0.262144 108361 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.262144 0.524288 62805 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.524288 1.000000 36220 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 1.000000 2.000000 17353 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 2.000000 4.000000 6835 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 4.000000 8.000000 2753 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 8.000000 16.000000 1845 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 16.000000 32.000000 2985 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 32.000000 64.000000 1773 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 64.000000 128.000000 4811 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 128.000000 256.000000 700 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 256.000000 512.000000 1487 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 512.000000 1024.000000 294 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 1024.000000 2048.000000 3 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 2048.000000 4096.000000 6 -- Toralf

1 0

Would you place your secrets or in worst case make your life
by zwiebeln 17 Feb '20

17 Feb '20

depended on a network that is 21 percent controlled by a single person that you don't know? https://nusenu.github.io/OrNetStats/allexitfamilies I think we should start an open debate on that fact, best ending up with giving some recommendations. I am sure that question is relevant to torproject.org as well. Lets start Paul

5 5

Fingerprint is marked rejected
by LeoR 17 Feb '20

17 Feb '20

Dear all, I am running a few Tor relays for more than 100 days. Since last Friday, I am getting the following message on each relay: [warn] http status 400 ("Fingerprint is marked rejected -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to bad-relays(a)lists.torproject.org mentioning your fingerprint(s)?") response from dirserver '171.25.193.9:443'. Please correct. The message above is also reported for other dirservers and prevents my relay for being online (they are all offline currently). I am just running Tor 0.4.2.6; no other activity is performed on any of my relays. I have already contacted the bad-relays list for the first relay offline; afterwards, I realized that all my few relays are off-line after more than 100 days of normal activity. Do you have similar experience? Sincerely, Leo

3 5

Bridge on Raspberry Pi Zero
by skarz 12 Feb '20

12 Feb '20

What is the current support for running Tor on Rasbian, and is running a bridge on a Pi Zero feasible? I vaguely remember there being repository / package / dependency issues with Raspbian last time I tried. Thanks!

5 6

Is This Leap in Bridge Clients Normal
by Eddie 10 Feb '20

10 Feb '20

Hi, For about 6 weeks now, I've been running a couple of obfs4 bridges, one on port 80, the other port 443. Up to yesterday, the port 80 one had seen zero traffic, when this started to be reported: Feb 09 13:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. Feb 09 19:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 533 unique clients. Feb 10 01:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 63 unique clients. Feb 10 07:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 212 unique clients. Feb 10 13:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 93 unique clients. Feb 10 19:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 61 unique clients. Is this kind of sudden usage normal. For the port 443 bridge, I have seen very little traffic at all, which surprises me as I thought that obfs4 bridges on port 443 were highly sought after. A relay search for "OhNoAnother" will pull up the details. Cheers.

2 1

Tor Meetup - Onionspace, Berlin [ February 6th, 6 pm ]
by gus 04 Feb '20

04 Feb '20

Dear Tor friends, This Thursday (February 6th), a Tor meetup will take place at Onionspace in Berlin. Starting at 6 pm, we hope you can join us to talk about the tor network and what we have been working on Tor Project. See you there! cheers, Gus Tor Meetup Berlin ================= When: Thursday, February 6th, 2020 Time: 6 - 7:30 pm Where: Gottschedstrasse 4, Entrance 4, 13357 Berlin (U Nauener Platz) Link: https://blog.torproject.org/tor-meetup-berlin-feb2020

1 0

Re: [tor-relays] Consensus Weight Dropping/Authority Issues?
by starlight.2018q2＠binnacle.cx 03 Feb '20

03 Feb '20

The rating shift experienced by your relays and many others is likely a consequence of the gradual phase-in of the SBWS scanner implementation in place of TorFlow. I for one find SWBS unimpressive. >Hello, > >I have been watching the consensus weight and bandwidth of all of my 50 exit nodes drop consistently over the past few months. I have not made any hardware changes in my data center and actual >customers have not complained about any performance issues. > >Operating systems and Tor version are up to date. I'm dedicating a significant portion of bandwidth to these nodes - 10gbit/sec. > >Am I having issues with the bandwidth authorities? > >I'm growing frustrated with my performance to resources ratio, I should be doing far better than this. > >Please throw ideas at me - open to any ideas. > >Thanks! >John >Quintex Alliance Consulting

3 2