Hi,
due to some recent and ongoing events related to a malicious entity running tor relays I'll start to pursue an idea that I had for some time: require non-empty ContactInfo (non-empty does not mean valid email address)
This is primarily a non-technical policy discussion which will take place on tor-dev@.
If you want to help right away and currently don't make use of the ContactInfo, please set it.
If you think such a change would negatively affect you please let me know (off-list is also fine if you prefer).
thanks, nusenu
On Tue, 05 Feb 2019 21:25:00 +0000 nusenu nusenu-lists@riseup.net wrote:
Hi,
due to some recent and ongoing events related to a malicious entity running tor relays I'll start to pursue an idea that I had for some time: require non-empty ContactInfo (non-empty does not mean valid email address)
This is primarily a non-technical policy discussion which will take place on tor-dev@.
It is very easy to fill ContactInfo with something meaningless, including automatically. Nicknames are required to be non-empty, did that stop any abuse? At its simplest bots or abusers can set ContactInfo to be the same as nickname; or to a different randomly generated word or phrase.
I suggest to carefully weigh all the possible positive effect from this (if any at all!!) against the effort required to advocate for and then implement such policy change.
On Wed, 6 Feb 2019 02:57:33 +0500 Roman Mamedov rm@romanrm.net wrote:
Nicknames are required to be non-empty, did that stop any abuse?
Correction: Nicknames default to "Unnamed" when unset. However did any of the recent abuse or suspected-malicious relays actually use "Unnamed"? From your E-Mails trying to reach out to some suspicious relay operators trying to get them to set proper MyFamily (and thanks for always being on the lookout for the network!), I got an impression that it is way more common to have some sort of randomly generated nicknames, than to run tons of "Unnamed" relays.
On 2/5/19, Roman Mamedov rm@romanrm.net wrote:
Nicknames are required to be non-empty, did that stop any abuse?
Correction: Nicknames default to "Unnamed" when unset. However did any of the recent abuse or suspected-malicious relays actually use "Unnamed"?
The consensus contains quite some fraction of unnamed, naturally some of which have been noted by various people as suspicious to in fact malicious.
Do nicknames or contacts fields stop anything, surely no guarantee there, but they might help resolve issues as they arise.
And if nicknames go away (status on that proposal), then contact is likely to absorb that function, including the current always present nature of nickname.
Hi,
On February 6, 2019 10:48:29 AM UTC, grarpamp grarpamp@gmail.com wrote:
...
And if nicknames go away (status on that proposal), then contact is likely to absorb that function, including the current always present nature of nickname.
There is no proposal to remove Nicknames.
The authorities don't vote for the Named flag any more, because relying on names to identify relays is fragile.
I'm not sure if we have removed the special handling code for Named yet.
T
-- teor ----------------------------------------------------------------------
Hi,
I was planning to bring up this issue but the other way around, ContactInfo, Nickname and Myfamily are non-enforceable so why should tor rely on spoofable information for its operation?
I saw some discussions about contacting hosting providers to reach out to server operators and I see you harassing people often for not setting MyFamily and that is outrageous!
A malicious actor will take the time to evade this policies so why bother at all, is tor getting designed for friendly or adversarial conditions?
Your language, as seen in the Trabia-Network thread and other posts alike, seems to imply an undeserved authority position: "please set MyFamily and contactInfo in your torrc to avoid getting rejected"
What? Rejected from what? Does one have to earn the right to commit time and resources for helping the network? Do relay operators need the tor network or is it the other way around? Maybe it's time for a reality check.
Regards, Emilian
On Tue, Feb 05, 2019 at 09:25:00PM +0000, nusenu wrote:
Hi,
due to some recent and ongoing events related to a malicious entity running tor relays I'll start to pursue an idea that I had for some time: require non-empty ContactInfo (non-empty does not mean valid email address)
This is primarily a non-technical policy discussion which will take place on tor-dev@.
If you want to help right away and currently don't make use of the ContactInfo, please set it.
If you think such a change would negatively affect you please let me know (off-list is also fine if you prefer).
thanks, nusenu
-- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
+1
Good to know that I'm not the only one finding this behavior of him wicked.
Emilian Ursu:
Hi,
I was planning to bring up this issue but the other way around, ContactInfo, Nickname and Myfamily are non-enforceable so why should tor rely on spoofable information for its operation?
I saw some discussions about contacting hosting providers to reach out to server operators and I see you harassing people often for not setting MyFamily and that is outrageous!
A malicious actor will take the time to evade this policies so why bother at all, is tor getting designed for friendly or adversarial conditions?
Your language, as seen in the Trabia-Network thread and other posts alike, seems to imply an undeserved authority position: "please set MyFamily and contactInfo in your torrc to avoid getting rejected"
What? Rejected from what? Does one have to earn the right to commit time and resources for helping the network? Do relay operators need the tor network or is it the other way around? Maybe it's time for a reality check.
Regards, Emilian
On Tue, Feb 05, 2019 at 09:25:00PM +0000, nusenu wrote:
Hi,
due to some recent and ongoing events related to a malicious entity running tor relays I'll start to pursue an idea that I had for some time: require non-empty ContactInfo (non-empty does not mean valid email address)
This is primarily a non-technical policy discussion which will take place on tor-dev@.
If you want to help right away and currently don't make use of the ContactInfo, please set it.
If you think such a change would negatively affect you please let me know (off-list is also fine if you prefer).
thanks, nusenu
-- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
+1
It looks like harassment.
Tyler Durden wrote:
+1
Good to know that I'm not the only one finding this behavior of him wicked.
Emilian Ursu:
Hi,
I was planning to bring up this issue but the other way around, ContactInfo, Nickname and Myfamily are non-enforceable so why should tor rely on spoofable information for its operation?
I saw some discussions about contacting hosting providers to reach out to server operators and I see you harassing people often for not setting MyFamily and that is outrageous!
A malicious actor will take the time to evade this policies so why bother at all, is tor getting designed for friendly or adversarial conditions?
Your language, as seen in the Trabia-Network thread and other posts alike, seems to imply an undeserved authority position: "please set MyFamily and contactInfo in your torrc to avoid getting rejected"
What? Rejected from what? Does one have to earn the right to commit time and resources for helping the network? Do relay operators need the tor network or is it the other way around? Maybe it's time for a reality check.
Regards, Emilian
On Tue, Feb 05, 2019 at 09:25:00PM +0000, nusenu wrote:
Hi,
due to some recent and ongoing events related to a malicious entity running tor relays I'll start to pursue an idea that I had for some time: require non-empty ContactInfo (non-empty does not mean valid email address)
This is primarily a non-technical policy discussion which will take place on tor-dev@.
If you want to help right away and currently don't make use of the ContactInfo, please set it.
If you think such a change would negatively affect you please let me know (off-list is also fine if you prefer).
thanks, nusenu
Came on guys, don't be so touchy. If it can harm the network it's not harassment to point it out.
Maybe, sometimes, it would be better to say things in a more gently way to tor operators that make mistakes.
Cheers Gigi
Il 10 febbraio 2019 20:12:49 CET, s7r s7r@sky-ip.org ha scritto:
+1
It looks like harassment.
Tyler Durden wrote:
+1
Good to know that I'm not the only one finding this behavior of him
wicked.
Emilian Ursu:
Hi,
I was planning to bring up this issue but the other way around, ContactInfo, Nickname and Myfamily are non-enforceable so why should tor rely on spoofable information for its operation?
I saw some discussions about contacting hosting providers to reach out to server operators and I see you harassing people often for not setting MyFamily and that is outrageous!
A malicious actor will take the time to evade this policies so why bother at all, is tor getting designed for friendly or adversarial conditions?
Your language, as seen in the Trabia-Network thread and other posts alike, seems to imply an undeserved authority position: "please set MyFamily and contactInfo in your torrc
to avoid getting rejected"
What? Rejected from what? Does one have to earn the right to commit time and resources for helping the network? Do relay operators need the tor network or is it the other way around? Maybe it's time for a reality check.
Regards, Emilian
On Tue, Feb 05, 2019 at 09:25:00PM +0000, nusenu wrote:
Hi,
due to some recent and ongoing events related to a malicious entity running tor relays I'll start to pursue an idea that I had for some time: require non-empty ContactInfo (non-empty does not mean valid email address)
This is primarily a non-technical policy discussion which will take place on tor-dev@.
If you want to help right away and currently don't make use of the ContactInfo, please set it.
If you think such a change would negatively affect you please let me know (off-list is also fine if you prefer).
thanks, nusenu
Perhaps it would be better to outright ban these relays with no warning? I'm sure that annoying those donating multiple relays will absolutely be encouraged to continue doing so.
(Or to be less sarcastic: I don't operate any tor relays at this time, but I do run public mirrors and a few other goodies and I'm eternally grateful to those that bother to notify me when there is a problem of any sort, especially configuration related -- I can't speak for tor relay operators, but I'm not sure that I'm seeing anything even in the same ballpark as harassment here)
On Sun, Feb 10, 2019, at 11:12, s7r wrote:
+1
It looks like harassment.
Tyler Durden wrote:
+1
Good to know that I'm not the only one finding this behavior of him wicked.
Emilian Ursu:
Hi,
I was planning to bring up this issue but the other way around, ContactInfo, Nickname and Myfamily are non-enforceable so why should tor rely on spoofable information for its operation?
I saw some discussions about contacting hosting providers to reach out to server operators and I see you harassing people often for not setting MyFamily and that is outrageous!
A malicious actor will take the time to evade this policies so why bother at all, is tor getting designed for friendly or adversarial conditions?
Your language, as seen in the Trabia-Network thread and other posts alike, seems to imply an undeserved authority position: "please set MyFamily and contactInfo in your torrc to avoid getting rejected"
What? Rejected from what? Does one have to earn the right to commit time and resources for helping the network? Do relay operators need the tor network or is it the other way around? Maybe it's time for a reality check.
Regards, Emilian
On Tue, Feb 05, 2019 at 09:25:00PM +0000, nusenu wrote:
Hi,
due to some recent and ongoing events related to a malicious entity running tor relays I'll start to pursue an idea that I had for some time: require non-empty ContactInfo (non-empty does not mean valid email address)
This is primarily a non-technical policy discussion which will take place on tor-dev@.
If you want to help right away and currently don't make use of the ContactInfo, please set it.
If you think such a change would negatively affect you please let me know (off-list is also fine if you prefer).
thanks, nusenu
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Email had 1 attachment:
- signature.asc 1k (application/pgp-signature)
On Sun, 10 Feb 2019 18:00:21 +0000 Emilian Ursu emu@emuadmin.com wrote:
What? Rejected from what? Does one have to earn the right to commit time and resources for helping the network?
Point is that by running tons of relays without proper MyFamily set, you are not helping the network, you are actively harming it, by putting users' anonymity at risk. See the full explanation:
https://medium.com/@nusenu/some-tor-relays-you-might-want-to-avoid-5901597ad...
Maybe you do this by mistake, or maybe you are maliciously trying to deanonymize users by correlating their traffic, how do we know. If there are strong suspicions to the latter, then Tor directory authorities may blacklist such group of relays from joining the network -- that's for the "rejected" part.
As for the wording, I suppose it's a mostly fruitless task, and at some point it can slip through that you feel there's no point in writing yet another of these mails if barely anyone is responding or acting accordingly anyways. So maybe this can result in somewhat blunt or succinct wording in a few of those.
It is not directly the topic of this thread but I'd like to give you some more context with regards to the "MyFamily" emails to clarify their intention.
To understand the motivation behind these emails we have to look at how the "bad-relays" process used to look in cases with no available contactInfo before I started sending these emails to tor-relays (short version):
1) someone reports some relay(s) 2) if directory authorities (or their proxies) agree to reject/badexit the relay(s), no information is send to the operator since no contact information is available and the operator has no chance to solve the issue before actions are taken 3) directory authorities apply the config change
in my opinion it were nice if there were at least an _attempt_ to reach out to the operator even with no contactInfo present before even considering any actions to give the operator the chance to solve things right away. This is where this list (tor-relays@) came in, it was used as an option of last resort (to attempt) to contact the operator since it is basically the canonical place to reach operators (and yes I agree that my wording in the last such email wasn't great which tells you my motivation to send them was decreasing).
As I understand some feel harassed by these emails, this was not my intention, sorry about that. So the old procedure (no emails to this list) will be restored.
With regards to why virii might be mad at me, that is probably related to a recent email of mine (see below). I can understand such an email will not be appreciated but the goal was to trigger a change to reduce the risk at hand. And in the end it has been solved promptly and the tor network is a tiny bit safer for its users - that is the overall goal here. Thanks for solving it.
-------- Forwarded Message -------- Subject: enn.lu publishes detailed relay traffic stats Date: Sun, 03 Feb 2019 22:37:00 +0000 From: nusenu To: bad-relays bad-relays@lists.torproject.org CC: info@enn.lu
6 months ago I asked enn.lu to take care of their public relay stats, I didn't hear from them since so I propose to reject one of their relays to rise awareness and hope they will take mitigating actions.
http://185.100.87.206/vnstat.xml http://185.100.87.207/vnstat.xml http://85.248.227.165/vnstat.xml http://85.248.227.164/vnstat.xml http://85.248.227.163/vnstat.xml
-------- Forwarded Message -------- Subject: please avoid publishing granular relay statistics Date: Fri, 10 Aug 2018 20:42:00 +0000 From: nusenu To: info@enn.lu
Hi,
you are publishing hour-level traffic statistics about your relays and bridges at https://stats.enn.lu/
to quote teor and the relay guide:
If you want to publish traffic statistics, you should aggregate all your relays' traffic over at least a week, then round that to the nearest 10 TiB (terabytes).
thanks, nusenu
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#SystemHealthMoni...
It would have helped if you contacted us again a week later when you didn't get a response from us because your mail has clearly not reached us and was lost (no trace of it in the logfiles) instead of directly going to the bad-relays list. That's simply putting us in a bad light for a problem that has been mostly mitigated some time ago without your notice.
P.s: the stats were never 100% accurate because we thought about this from the beginning and had cronjobs artificially creating non Tor related traffic.
Am 11. Februar 2019 22:09:00 MEZ schrieb nusenu nusenu-lists@riseup.net:
It is not directly the topic of this thread but I'd like to give you some more context with regards to the "MyFamily" emails to clarify their intention.
To understand the motivation behind these emails we have to look at how the "bad-relays" process used to look in cases with no available contactInfo before I started sending these emails to tor-relays (short version):
- someone reports some relay(s)
- if directory authorities (or their proxies) agree to reject/badexit
the relay(s), no information is send to the operator since no contact information is available and the operator has no chance to solve the issue before actions are taken 3) directory authorities apply the config change
in my opinion it were nice if there were at least an _attempt_ to reach out to the operator even with no contactInfo present before even considering any actions to give the operator the chance to solve things right away. This is where this list (tor-relays@) came in, it was used as an option of last resort (to attempt) to contact the operator since it is basically the canonical place to reach operators (and yes I agree that my wording in the last such email wasn't great which tells you my motivation to send them was decreasing).
As I understand some feel harassed by these emails, this was not my intention, sorry about that. So the old procedure (no emails to this list) will be restored.
With regards to why virii might be mad at me, that is probably related to a recent email of mine (see below). I can understand such an email will not be appreciated but the goal was to trigger a change to reduce the risk at hand. And in the end it has been solved promptly and the tor network is a tiny bit safer for its users - that is the overall goal here. Thanks for solving it.
-------- Forwarded Message -------- Subject: enn.lu publishes detailed relay traffic stats Date: Sun, 03 Feb 2019 22:37:00 +0000 From: nusenu To: bad-relays bad-relays@lists.torproject.org CC: info@enn.lu
6 months ago I asked enn.lu to take care of their public relay stats, I didn't hear from them since so I propose to reject one of their relays to rise awareness and hope they will take mitigating actions.
http://185.100.87.206/vnstat.xml http://185.100.87.207/vnstat.xml http://85.248.227.165/vnstat.xml http://85.248.227.164/vnstat.xml http://85.248.227.163/vnstat.xml
-------- Forwarded Message -------- Subject: please avoid publishing granular relay statistics Date: Fri, 10 Aug 2018 20:42:00 +0000 From: nusenu To: info@enn.lu
Hi,
you are publishing hour-level traffic statistics about your relays and bridges at https://stats.enn.lu/
to quote teor and the relay guide:
If you want to publish traffic statistics, you should aggregate all
your relays'
traffic over at least a week, then round that to the nearest 10 TiB
(terabytes).
thanks, nusenu
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#SystemHealthMoni...
tor-relays@lists.torproject.org