Hi,
in the last two days someone started generating a steady amount of new relay fingerprints on a single IP:port (2 per hour, actually a lot more than that but only to make it into the consensus) [1].
I'm surprised that actually both of them end up in the consensus.
example: https://collector.torproject.org/recent/relay-descriptors/consensuses/2015-0...
search for "67.173.119.40 51256" - you will find it twice.
Does that make sense or is this a bug?
btw: Why do dir auths include non-running relays in their votes (flag line is "s" only), instead of not voting for them at all?
thanks!
[1] http://article.gmane.org/gmane.network.onion-routing.ornetradar/113
nusenu transcribed 2.5K bytes:
Hi,
in the last two days someone started generating a steady amount of new relay fingerprints on a single IP:port (2 per hour, actually a lot more than that but only to make it into the consensus) [1].
I'm surprised that actually both of them end up in the consensus.
example: https://collector.torproject.org/recent/relay-descriptors/consensuses/2015-0...
search for "67.173.119.40 51256" - you will find it twice.
Does that make sense or is this a bug?
Hey nusenu,
The normal setting for AuthDirMaxServersPerAddr is 2, so a relay can use the same IP twice. See get_possible_sybil_list(). [0] We don't check whether the same IP:port pair was used multiple times, (I would assume) because 1) you can't bind to the same port twice, and 2) even if you could, you'd reply half the time with the wrong set of keys and the other end would tear down the circuit/connection. You're right that this relay shouldn't be in the consensus twice (or at all).
FWIW, my guess it that that relay is trying to attack the HSDir hashring by churning through ID keys, rather than actually trying to get multiple copies of the same IP:port pair listed in the consensus.
[0]: https://gitweb.torproject.org/tor.git/tree/src/or/dirserv.c?id=c84f3c91#n208...
Best Regards,
-
isis -
nusenu