Hi Nicolas,
according to aeris (CC) one(?) [1] of your relays got seized/compromised [2].
Did you report it to tor directory authorities, so they can blacklist the relay?
thanks, nusenu
[1] InFlames - C46A33E7E56F4F3FF2D36308A37E3DA21CD100FB [2] https://twitter.com/aeris22/status/865317501525045248
if your relay is on this list and has no comment in the last column, please let us know.
the goal would be to have a seized/not seized comment in each row.
https://gist.github.com/nusenu/3d7bbeb7c97af591d65003b4bfe70021
Hey,
any idea how to avoid the guard flag at this time? My only idea is to trottle down the speed but this is a bad solution imho.
I don't want to shut it down but maybe they were smart enough to think about what they did? :D
Thanks! Tobias
Am 20.05.2017 um 01:00 schrieb nusenu:
if your relay is on this list and has no comment in the last column, please let us know.
the goal would be to have a seized/not seized comment in each row.
https://gist.github.com/nusenu/3d7bbeb7c97af591d65003b4bfe70021
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sat, May 20, 2017 at 04:01:04AM +0200, Tobias Sachs wrote:
any idea how to avoid the guard flag at this time? My only idea is to trottle down the speed but this is a bad solution imho.
I don't think there's an easy way.
If you set "DirCache 0" in your torrc file, then you will still get the Guard flag, but you'll lose the V2Dir flag, which will make clients running 0.3.0.x and later decide that you're not usable as a Guard.
But the stable Tor Browser releases still ship Tor 0.2.9.x, which is willing to use Guards that don't have the V2Dir flag.
One answer that is still crummy but is less crummy than throttling is to give the relay some downtime every so often, so its weighted-fractional-uptime doesn't look attractive, so the authorities won't give it the Guard flag. You could compensate for the downtime by running two relays, and swapping between them.
But that's a lot of work. What is your goal here? If the goal is to avoid running a thing on the Internet that scared incompetent cops might try to mess with, then I would be tempted to argue that you'll have better success (albeit maybe still not much) fixing the cops.
(Or empowering and educating the ISPs, and/or choosing hosting at an ISP that is already empowered and educated. Maybe the people at OVH would have some statement like "I could do nothing, they were cops", but there are plenty of things they could have chosen to do to help everybody understand what's going on, then and in the future. Or maybe they did these things? It's hard to know from the outside.)
In this particular case, it looks like a bunch of people who don't understand the Internet went berserk in response to Wannacry, and it also looks like they're done going berserk in this particular case. It's hard to know how to extrapolate from this one data point, but I would hope it will be a good long while until some other situation like this, and also there's nothing to say it will necessarily happen at OVH again next time.
Oh, and while I have your attention: if anybody wants to do some historical Tor directory data mining, so we can make it less scary when bad guys steal your relay identity key, check out https://trac.torproject.org/projects/tor/ticket/22308 "Consider resetting wfu/mtbf/tk values for relays when they switch IP addresses"
--Roger
nusenu:
if your relay is on this list and has no comment in the last column, please let us know.
the goal would be to have a seized/not seized comment in each row.
https://gist.github.com/nusenu/3d7bbeb7c97af591d65003b4bfe70021
@aeris: since you reached out to some of the operators: Could you let us know which relay ops you did contact already? (only those on that table that have no comment are of interest)
thanks, nusenu
tor-relays@lists.torproject.org