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.
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 if they anyway will disappear again soon. I did it that way with all relays before and when i am sure that the hoster is okay with me and that i am okay with the hoster i always included them in MyFamily.
In the received email nothing was written that someone might expect an answer from me so i deleted that email and to not trigger that warning again i deleted the contact info from these specific relays for now.
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.
I explained why i do not have a correct MyFamily setup and i explained that one of these relays is not operated by me even if it has the same name than one of my relays.
The answer of the bad-relays mailing list was that its important for them to know that one of the relays tried to look like me and that i can use a third-party tool for setting up the MyFamily and that further discussion about the MyFamily is more suitable for the relays mailinglist.
What i learned from that:
- 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 could do an end-to-end correlation attack (I knew that already and would not use the same name and contact info on my relays if i would like to do that)
- It is possible for them to pin relays to specific operators without relying on the contact info or MyFamily entrys (I assume they guess that by looking at the relays names because otherwise they hadn't put a relay which is not operated by me into my warning message)
- If setting up the MyFamily option is too painful for you then you can use a third party tool which is not part of the torproject
- Relays names are free to choose and double entrys are okay but if someone operates an relay with a name you choosed before then you can report that operator to the bad-relays list because that operator might be malicious (Thankfully my relays are not called "Unnamed")
So for what reason do i set the MyFamily option beside making a Hidden Service Guard discovery attack more easy?
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.
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.
[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)
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.
- reducing the risk for tor users that might become victims if some operator gets compromized (with all its relays)
- transparency Every relay operator should declare their relay group to allow everybody to measure their network fraction (Sybil detection).
- 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
- 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").
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).
[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@lists.torproject.org so they can be removed from the network for impersonating your contactInfo.
https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#torrpi1405gm...
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 | +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+
On Fri, 21 Feb 2020 21:23:00 +0000 nusenu nusenu-lists@riseup.net wrote:
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.
What helps greatly is that the MyFamily string on each relay doesn't have to list all OTHER relays, it can list just ALL relays, including that one, i.e. simply be the same on all relays. This should vastly simplify any automation that you might think of.
Secondly, even though not recommended at all, MyFamily accepts nicknames; If there's no practical way for you to automate it (such as to set up a centralized system to manage torrcs and push them to hosts), you can make a MyFamily like this:
MyFamily MyNode1,MyNode2,MyNode3,...,MyNodeN
That way at any time you can spin up to N relays named "MyNode" 1 to N (or other arbitrary prefix of your choosing), and they will automatically join your family without any torrc updates anymore.
- 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.
...of course using Nicknames doesn't provide this, so in case using such a system you should keep an eye on relay list for your prefix:
https://metrics.torproject.org/rs.html#search/MyNode
and stop doing so in case you see unfamiliar entries there.
Hi Michael,
On 22 Feb 2020, at 11:30, Roman Mamedov rm@romanrm.net wrote:
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.
What helps greatly is that the MyFamily string on each relay doesn't have to list all OTHER relays, it can list just ALL relays, including that one, i.e. simply be the same on all relays. This should vastly simplify any automation that you might think of.
Also, it's totally ok to list old relay keys in MyFamily, even if those relays aren't running any more. Tor clients ignore down relays, so you can clear out old fingerprints whenever you have time.
Tor also supports "%include (path)" lines in torrcs, which include the contents of the file at that path.
So you can put all your relay fingerprints in a file, scp it to your relays, and then issue a HUP (to reload the config).
(If you have logrotate installed, it should issue a HUP every day to rotate tor's logs. So maybe you can skip that step.)
It's a bit of a pain, I know. I've done it with about 20 relays before.
We'd like to have a better system, maybe with a single shared key for each family. But that's a long-term plan.
T
On 22.02.2020 08:42, teor wrote:
Tor also supports "%include (path)" lines in torrcs, which include the contents of the file at that path.
(If you have logrotate installed, it should issue a HUP every day to rotate tor's logs. So maybe you can skip that step.)
It's a bit of a pain, I know.
No, that's great! Thank you. I didn't know include path in torrc yet. ;-)
Secondly, even though not recommended at all, MyFamily accepts nicknames; If there's no practical way for you to automate it (such as to set up a centralized system to manage torrcs and push them to hosts), you can make a MyFamily like this:
MyFamily MyNode1,MyNode2,MyNode3,...,MyNodeN
Don't use nicknames in MyFamily. You can preemptively generate as many relay keys as you want and use their fingerprints in MyFamily so you don't have to bother about changing old configs when you add new relays as long as you use these preemptively generated keys.
On 2/22/20 10:55 AM, nusenu wrote:
You can preemptively generate as many relay keys as you want and use their fingerprints in MyFamily so you don't have to bother about changing old configs when you add new relays as long as you use these preemptively generated keys.
And if you're already there then you can then deal with offline keys too ;-)
Toralf Förster:
On 2/22/20 10:55 AM, nusenu wrote:
You can preemptively generate as many relay keys as you want and use their fingerprints in MyFamily so you don't have to bother about changing old configs when you add new relays as long as you use these preemptively generated keys.
And if you're already there then you can then deal with offline keys too ;-)
I believe that is a different matter. If you run >2 relays without configuration management and don't want to update torrc file, you probably don't want to run in OfflineMasterKey mode either.
So this is another reason to seriously consider configuration management if you run
1Gbit/s of tor bandwidth. If you want to consider a state of the art relay setup.
tor-relays@lists.torproject.org
-
[REDACTED] -
lists＠for-privacy.net -
nusenu -
Roman Mamedov -
teor -
Toralf Förster