"Potentially dangerous relay groups"
pa011@web.de wrote:
there is that list of "potentially_dangerous_relaygroups" you published. Could yo please emphasize a bit more on what brings a relay on that list, apart from incorrect given MyFamily which doesnt seem to be always the case. I mean I see quite a few well respected names on that list ?
to quote from https://github.com/ornetstats/stats (1) "dangerous" in the sense that a tor client might has a chance to use more than one of these relays in a single circuit (2) these relays are aggregated based on contact information (3) if their groupsize is bigger than their effective family size and they are operated in more than one /16 network block they are listed (4) this list might contain false-positives (contact information is not authenticated) Does that answer your question? I probably should also filter entries where two out of guard_prob, middle_prob and exit_prob are 0 since that means that (1) is never the case - iff onionoo is right about these probabilities.
Always watching my ass to be a good old Tor operator, I got my nodes on the list. Always fun to see how one time not updating all your MyFamily's gets you marked for life xD Time for some conf-updating. On 27/09/16 19:37, nusenu wrote:
pa011@web.de wrote:
there is that list of "potentially_dangerous_relaygroups" you published. Could yo please emphasize a bit more on what brings a relay on that list, apart from incorrect given MyFamily which doesnt seem to be always the case. I mean I see quite a few well respected names on that list ?
to quote from https://github.com/ornetstats/stats (1) "dangerous" in the sense that a tor client might has a chance to use more than one of these relays in a single circuit (2) these relays are aggregated based on contact information (3) if their groupsize is bigger than their effective family size and they are operated in more than one /16 network block they are listed (4) this list might contain false-positives (contact information is not authenticated)
Does that answer your question?
I probably should also filter entries where two out of guard_prob, middle_prob and exit_prob are 0 since that means that (1) is never the case - iff onionoo is right about these probabilities.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Tim Semeijn Babylon Network PGP: 0x2A540FA5 / 3DF3 13FA 4B60 E48A E755 9663 B187 0310 2A54 0FA5
Always watching my ass to be a good old Tor operator, I got my nodes on the list. Always fun to see how one time not updating all your MyFamily's gets you marked for life xD
Time for some conf-updating.
I wouldn't bother doing that manually. I guess a good lazy operator automates all the things(tm).
Sounds like CloudFlare's threat policy. On Sep 27, 2016 2:36 PM, "Tim Semeijn" <noc@babylon.network> wrote:
Always watching my ass to be a good old Tor operator, I got my nodes on the list. Always fun to see how one time not updating all your MyFamily's gets you marked for life xD
Time for some conf-updating.
On 27/09/16 19:37, nusenu wrote:
pa011@web.de wrote:
there is that list of "potentially_dangerous_relaygroups" you published. Could yo please emphasize a bit more on what brings a relay on that list, apart from incorrect given MyFamily which doesnt seem to be always the case. I mean I see quite a few well respected names on that list ?
to quote from https://github.com/ornetstats/stats (1) "dangerous" in the sense that a tor client might has a chance to use more than one of these relays in a single circuit (2) these relays are aggregated based on contact information (3) if their groupsize is bigger than their effective family size and they are operated in more than one /16 network block they are listed (4) this list might contain false-positives (contact information is not authenticated)
Does that answer your question?
I probably should also filter entries where two out of guard_prob, middle_prob and exit_prob are 0 since that means that (1) is never the case - iff onionoo is right about these probabilities.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Tim Semeijn Babylon Network
PGP: 0x2A540FA5 / 3DF3 13FA 4B60 E48A E755 9663 B187 0310 2A54 0FA5
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, 27 Sep 2016 21:24:59 +0200 Tim Semeijn <noc@babylon.network> wrote:
Always watching my ass to be a good old Tor operator, I got my nodes on the list. Always fun to see how one time not updating all your MyFamily's gets you marked for life xD
Time for some conf-updating.
To possibly simplify this a bit, consider that: *) It doesn't hurt anything if a node has itself listed in its own MyFamily. You can just use the same MyFamily string in all your configs. *) Give up on listing fingerprints, instead simply list nicknames. Any harm this can possibly cause, is largely hypothetical. So if that simplifies management for you, just go for it. *) Over-listing is better than under-listing, so you can add ALL node nicknames you currently use or plan to use soon, and don't worry about listing some which are down at the moment, or not set up just yet. -- With respect, Roman
Always watching my ass to be a good old Tor operator, I got my nodes on the list. Always fun to see how one time not updating all your MyFamily's gets you marked for life xD
Time for some conf-updating.
To possibly simplify this a bit, consider that:
*) It doesn't hurt anything if a node has itself listed in its own MyFamily. You can just use the same MyFamily string in all your configs.
*) Give up on listing fingerprints, instead simply list nicknames. Any harm this can possibly cause, is largely hypothetical. So if that simplifies management for you, just go for it.
I would recommend to use fingerprints: https://www.torproject.org/docs/tor-manual.html.en
When listing a node, it’s better to list it by fingerprint than by nickname: fingerprints are more reliable.
To possibly simplify this a bit, consider that:
*) It doesn't hurt anything if a node has itself listed in its own MyFamily. You can just use the same MyFamily string in all your configs. Roman
Would that unknown fact be the reason so many MyFamily sections are botched? With changing fingerprints through updating or VPS problems it has been difficult to keep up-to-date MyFamily entries unique to each relay. One list is much easier. Robert
In torrc, an idea...?? *MyFamily http://mydomain.org/myfamily.txt* So > there will be only 1 list to update / maintain by the operator(s). Ctrl+F to find if a fingerprint is already here (for lazy guyz)... if not, Ctrl-V to add the new fingerprint, if Atlas shows a down fingerprint, Ctrl+F too... then /service tor reload/ to eat the new txt file?
One list is much easier.
Robert
-- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5
On Tue, Sep 27, 2016 at 4:38 PM, Roman Mamedov <rm@romanrm.net> wrote:
*) Give up on listing fingerprints, instead simply list nicknames.
No. Fingerprints are what to use here. Please do not use nicknames. Ignoring the ambiguous assertions you'd be making with nicks, it inserts the same ambiguity into downstream consensus parsers. Just grok FP's your configs and assemble the family like any good admin. Besides, other than for simply announcing a vanity tag, nicks are going away in every area they are currently accepted as config input, so don't get used to them as such. See tickets 12898, etc. Note in current consensus, there are about 1500 different good strict FP only family lines, and 60 different bad essentially random lines to fix. '^family( \$[0-9A-F]{40})+$' Ticket 12799 will apply further needed sanity to fingerprints.
On Wed, 28 Sep 2016 02:38:37 -0400 grarpamp <grarpamp@gmail.com> wrote:
On Tue, Sep 27, 2016 at 4:38 PM, Roman Mamedov <rm@romanrm.net> wrote:
*) Give up on listing fingerprints, instead simply list nicknames.
No. Fingerprints are what to use here. Please do not use nicknames.
Any actual rationale, other than "do as I say"? And aside from linking to the man page which doesn't provide one EITHER. The only problem I can imagine with this is that Nefarious People can run a same fingerprint relay with the same MyFamily string as mine, and by that join my family, possibly knocking out one of my actual relays out of it. But what exactly would anyone achieve with that, is entirely unclear.
Besides, other than for simply announcing a vanity tag, nicks are going away in every area they are currently accepted as config input, so don't get used to them as such. See tickets 12898, etc.
Then expect the number of people to even bother with MyFamily, to dwindle further. -- With respect, Roman
On Wed, Sep 28, 2016 at 2:53 AM, Roman Mamedov <rm@romanrm.net> wrote:
Any actual rationale, other than "do as I say"? And aside from linking to the man page which doesn't provide one EITHER.
The ambiguity problems are long known, leading to it going away. Feel free to search historical references and better document things. Though I endorse it, I didn't make it up, so it's not me.
The only problem I can imagine with this is that Nefarious People can run a my family, possibly knocking out one of my actual relays out of it. But what
It may require bidirectional assertion, at least it should. See search like above, and torspec.
Then expect the number of people to even bother with MyFamily, to dwindle
The line counts just posted debunk this. Both fp and nick are currently accepted (as well as random garbage) so no dwindle possibility there, and when they bother, orders of magnitude bother to do it right.
On 28.09.2016 08:53, Roman Mamedov wrote:
Any actual rationale, other than "do as I say"? And aside from linking to the man page which doesn't provide one EITHER.
Key fingerprints are technically much closer to being IDs than nicknames, which are nothing but short strings that can - and do - change at a whim. I think that grarpamp's recommendation to use fingerprints is much better advice than your choice of using nicknames. I only ever use fingerprints in MyFamily. -Ralph
On Wed, 28 Sep 2016 11:41:16 +0200 Ralph Seichter <tor-relays-ml@horus-it.de> wrote:
Key fingerprints are technically much closer to being IDs than nicknames, which are nothing but short strings that can - and do - change at a whim.
We're talking MyFamily, so it's you who is in control of all the nicknames, and it's only by your whim they may or may not change. Still did not see any concrete practical arguments to why fingerprints are worth the additional hassle, especially when what we see in reality is nicknames working there perfectly well and causing zero issues whatsoever for years. -- With respect, Roman
On 28.09.2016 11:52, Roman Mamedov wrote:
We're talking MyFamily, so it's you who is in control of all the nicknames, and it's only by your whim they may or may not change.
And your point is what? When I last opted for a different naming scheme, I only had to verify that the names were not already taken. Had I followed your advice of using nicknames in MyFamily, I would have been required to update all my nodes, but since I am using fingerprints only, it was not an issue. Also, Atlas URLs are based on fingerprints, showing that fingerprints relate to "identity" in the Tor network.
Still did not see any concrete practical arguments to why fingerprints are worth the additional hassle, especially when what we see in reality is nicknames working there perfectly well and causing zero issues whatsoever for years.
No idea what "additional hassle" you are talking about, and even if you personally might have difficulties with fingerprints, it does not mean that other people cannot, or should not, use them. Keeping the correct fingerprints in MyFamily is easily done. Personally, I like to generate my nodes' torrc files based on shared settings. Obviously you can choose to use nicknames if you like to. It is just not reasonable to state, without any data to back it up, that using finger- prints over nicknames causes "the number of people to even bother with MyFamily to dwindle further", as you put it. -Ralph
Why isn't MyFamily a family name, instead of a list of members? I see no downside to having an unauthenticated advisory don't-route-through-me-if-you-also-route-through... So, all of my nodes could have MyFamilyName org.example On Sep 28, 2016 05:52, "Roman Mamedov" <rm@romanrm.net> wrote:
On Wed, 28 Sep 2016 11:41:16 +0200 Ralph Seichter <tor-relays-ml@horus-it.de> wrote:
Key fingerprints are technically much closer to being IDs than nicknames, which are nothing but short strings that can - and do - change at a whim.
We're talking MyFamily, so it's you who is in control of all the nicknames, and it's only by your whim they may or may not change.
Still did not see any concrete practical arguments to why fingerprints are worth the additional hassle, especially when what we see in reality is nicknames working there perfectly well and causing zero issues whatsoever for years.
-- With respect, Roman
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Wed, Sep 28, 2016 at 7:08 AM, grarpamp <grarpamp@gmail.com> wrote:
On Wed, Sep 28, 2016 at 6:24 AM, Chad MILLER <chad@cornsilk.net> wrote:
Why isn't MyFamily a family name, instead of a list of members? I see no downside to having an unauthenticated
Because anyone can assert the string and shared strings can't cross certify each other.
So? A relay can always have behaved badly. What's the harm in you fraudulently claiming to be in family com.example.chadmiller ? A user's path won't have passed through both you and me, but you could have prevented traffic from passing through you any time. At worst, you get to participate in a user's path and exclude me from participating. That's no worse than you setting your machine on fire and me participating. -- Chad Miller chad.org gpg:FE9782A4C4F1ACBB
On 09/28/2016 02:01 PM, Chad MILLER wrote:
So? A relay can always have behaved badly. What's the harm in you fraudulently claiming to be in family com.example.chadmiller ? A user's path won't have passed through both you and me, but you could have prevented traffic from passing through you any time. At worst, you get to participate in a user's path and exclude me from participating. That's no worse than you setting your machine on fire and me participating.
1) Bad actor sets up a bunch of relays fraudulently joining the majority of other relays. 2) Path selection of clients will now effectively prefer the bad actor's relays on which he performs eavesdropping, traffic analysis, or other nasty things. The bad actor could also leave a few of his bad relays without family in order not to uncover himself so easily. I am in favor of a scheme where the process of joining a family is authenticated.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Personally I like what Petrusko provided the most
In torrc, an idea...??
*MyFamily http://mydomain.org/myfamily.txt*
the list being a plaintext file of fingerprints seperated by newlines, and if the server having that family list is not in that mentoined family list, it's not authorized to be in that family. Altho this will create an overhead of making a new http request when looking for an Tor node, which may be a problem. it actually isn't possibly at all without leaking the real IP to said server, or someone needs to be more creative then me :s But on the other hand, if you run more then 4 nodes, just let puppet or any other system managment tool fill in the MyFamily field, shouldn't be that hard imo On 09/28/2016 02:44 PM, Random Tor Node Operator wrote:
On 09/28/2016 02:01 PM, Chad MILLER wrote:
So? A relay can always have behaved badly. What's the harm in you fraudulently claiming to be in family com.example.chadmiller ? A user's path won't have passed through both you and me, but you could have prevented traffic from passing through you any time. At worst, you get to participate in a user's path and exclude me from participating. That's no worse than you setting your machine on fire and me participating.
1) Bad actor sets up a bunch of relays fraudulently joining the majority of other relays. 2) Path selection of clients will now effectively prefer the bad actor's relays on which he performs eavesdropping, traffic analysis, or other nasty things.
The bad actor could also leave a few of his bad relays without family in order not to uncover himself so easily.
I am in favor of a scheme where the process of joining a family is authenticated.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJX677wAAoJEE6fMe4ysJ7McdUH/1TzCArbxb0kZ1SDwc1P01LE 5bWvTtFj++C3PqcDzeiN3UrzVwm1AtJLa5pW3yZlAorgHksL98oX/om4EY2DKptz IpEreQeobE/bd6c9Klhjc+FwVwW6Lb3D61KbeZkxE9+nyXrMjWUS8Nws0REZgKhc IW6Q6kmuBt48yudbTm/dBAYPPND290ebGDuF7EDhsS9shx3+SxchuXYapwh8S1Xi mZENyKDqxxcZT/8Ua7xMTreOzFFfscpcbFBnsKCbMjqJg0/bGKENyASoNJVQha7t xmd5dL4fLyLrDlsi3AK4IVFCuWp3rsFpZZJ5An4FPHUe6NBSAX7pbfRko0cmq/E= =Xptb -----END PGP SIGNATURE-----
Am 27.09.2016 um 19:37 schrieb nusenu:
pa011@web.de wrote:
there is that list of "potentially_dangerous_relaygroups" you published. Could yo please emphasize a bit more on what brings a relay on that list, apart from incorrect given MyFamily which doesnt seem to be always the case. I mean I see quite a few well respected names on that list ?
to quote from https://github.com/ornetstats/stats (1) "dangerous" in the sense that a tor client might has a chance to use more than one of these relays in a single circuit (2) these relays are aggregated based on contact information (3) if their groupsize is bigger than their effective family size and they are operated in more than one /16 network block they are listed (4) this list might contain false-positives (contact information is not authenticated)
Does that answer your question?
I probably should also filter entries where two out of guard_prob, middle_prob and exit_prob are 0 since that means that (1) is never the case - iff onionoo is right about these probabilities.
nusenu, great respect of your work at first and thank you for the answer provided as well. It - plus the follow up from that many contributors - did answer my questions apart from two left: - should only Markus be contacted instead of lets say at least all the folks with more than 2 notes to make them aware? - how could it take nearly a week for that serious discussion to start? I tend to agree with what has been written "I am in favour of a scheme where the process of joining a family is authenticated." Personally I will correct my entries soon to get me off that list :-)
It - plus the follow up from that many contributors - did answer my questions apart from two left:
- should only Markus be contacted instead of lets say at least all the folks with more than 2 notes to make them aware?
I contacted many of the most relevant operators with incorrect MyFamily setting in the past years. ansible-relayor [1] was also born to provide a solution for the MyFamily "problem". The email to Markus was just triggered by the OrNetRadar email that in turn has been trigged by the fact that he added 3 relays on 2016-09-22. MyFamily is not very relevant, but I use MyFamily data to to aggregate relays for lists like https://raw.githubusercontent.com/ornetstats/stats/master/o/main_operators_b... and if torpids would also set a proper MyFamily their ranking would be better (because more relays would be aggregated into their group).
I tend to agree with what has been written "I am in favour of a scheme where the process of joining a family is authenticated." Personally I will correct my entries soon to get me off that list :-)
people interested in that topic might want to read: https://gitweb.torproject.org/torspec.git/tree/proposals/242-better-families... https://trac.torproject.org/projects/tor/ticket/5565 [1] https://github.com/nusenu/ansible-relayor
participants (12)
-
Chad MILLER -
Corné Oppelaar -
grarpamp -
I -
nusenu -
pa011 -
Petrusko -
Ralph Seichter -
Random Tor Node Operator -
Roman Mamedov -
Tim Semeijn -
Tristan