This application claims to identify bad Tor nodes for the purpose of excluding them from use:
http://xqz3u5drneuzhaeo.onion/users/badtornodes/
Anyone have any thoughts on this? The sum of bad-exit-flags (8), exit nodes that alter payload (4), and long-term-misconfigured (27) suggests excluding 39 nodes within the Tor config file.
Is this reasonable? Are these exclusions appropriate for relays, or for end users, or neither, or both?
On Wed, Feb 01, 2012 at 11:36:57PM -0500, Steve Snyder wrote:
This application claims to identify bad Tor nodes for the purpose of excluding them from use:
http://xqz3u5drneuzhaeo.onion/users/badtornodes/
Anyone have any thoughts on this?
In general it is a poor plan to change your routing strategy in a way that makes you different from most Tor users. If you change it enough, you end up making a signature for your behavior where an attacker can say "hey, that's the guy who never uses German relays". The result is that you harm your anonymity. Nobody has really researched how much harm comes from how much difference -- and we recommend against doing things that are poorly understood.
The sum of bad-exit-flags (8),
As far as I can tell, http://xqz3u5drneuzhaeo.onion/users/badtornodes/overview.html#blocking are all tiny relays so it doesn't much matter whether you badexit them (you're probably never going to encounter them in practice anyway).
For the question of exit relays in Iran, see https://trac.torproject.org/projects/tor/ticket/4207 https://trac.torproject.org/projects/tor/ticket/4923
exit nodes that alter payload (4),
It would be great if people would actually report these to us. I believe that two of those four are ones we've already noticed and set the badexit flag on network-wide, and two of those four aren't around anymore.
and long-term-misconfigured (27)
It would be great if people would report these too, if they are actually having problems.
In theory, Mike Perry's TorFlow scripts out to be able to automatically recognize when a relay is buckling under the load and starting to fail connections. In practice it's not there yet, and he could sure use some help since we're also asking him to maintain our Firefox fork.
suggests excluding 39 nodes within the Tor config file.
Is this reasonable? Are these exclusions appropriate for relays, or for end users, or neither, or both?
I'd go with 'neither'.
This is a community that looked at a relay with the nickname "NSAFortMeade" and freaked out because it was clearly an NSA-run node. You can pick your nickname to be whatever you like. If the NSA ran a relay (which it makes no sense for them to do, since they have already suborned major telco networks like AT&T so they'd do better to watch *other* peoples' relays), why the heck would they name it NSAFortMeade? And if somebody came to you claiming you'd better not use it because omg tin foil hat, how much should you listen to the rest of their recommendations?
Now, that doesn't mean we don't need help trying to make sure all the relays are behaving correctly. But a person who sets up a Tor hidden service, and clearly puts quite a bit of effort into it, but never tries to contact the Tor developers or the Tor directory authority operators? Maybe he just needs you to help him communicate with us. :)
The right way to set badexit flags is to do it network-wide so we don't fragment the set of possible path selection behaviors for clients.
Hope that helps, --Roger
tor-relays@lists.torproject.org