On Wed, 8 Feb 2017 18:22:33 +1100 teor teor2345@gmail.com wrote:
On 8 Feb 2017, at 18:03, Andrew Deason adeason@dson.org wrote:
And they even gave instructions for how to block ranges from individual exits: https://www.webiron.com/supporthome/view-article/32-blocking-traffic-from-tor-exit-nodes.html
[...]
And it's wrong:
Tor attempts to find the closest exit node to the end point in attempts to speed up service. In most cases, because of this it is possible to curb abuse originating from the same places by blocking outbound traffic from just a few exit nodes.
Just to be clear for the archives etc, I believe you are quoting text from that page, and that text is incorrect. Tor doesn't choose exits that way (unless a user specifically chooses a set of exits near the target or something); that would be silly.
From my current conversation with them, they are aware of at least some suggested ways of blocking tor entirely, but claim some issues with doing so. (Something having to do with exit node IPs changing too frequently, making the existing methods useless.)
I am not sure if there are real technical limitations, or there is just a misunderstanding. Since I don't work with the technical details of tor in and out every day, I'm a little hesitant to be arguing with them about the various technical details, since I might get something wrong.
And of course, if there _are_ actual problems with the mechanisms of tor blacklisting, I can't do anything about it myself, and we have to play "telephone" with me reporting some issue second-hand or whatever.
They are probably using the wrong list, there are reliable lists maintained by Tor, as far as I know.
As far as I can tell, the specific complaint here was that TorDNSEL caches results for 30 minutes; I can see the results indeed give a TTL of 30 minutes. You can just ignore the TTL though, but maybe they were also (allegedly) seeing the information itself be 30 minutes stale. I don't know.
Anyway, so the claim (I think) is that the TorDNSEL data would be out of date, and they would block based on that, so they would be missing some. Attackers would then try running their exploit repeatedly until they found an exit that works; and since (they claim) tor exit IPs change so frequently, this would always be a problem. (Even if all of this were true, how this is any better at all from having individual exits block the target ranges via ExitPolicy from their automated reports is beyond me.)
It also seems like a service like theirs wouldn't be using TorDNSEL, but instead maybe doing something parsed from consensus itself, but that's just me.
So... I was wondering if there's someone I should "pass off" to :)
Ask them to join tor-access@ and explain their issues?
Yeah, I hadn't seen your other message when I sent this. It seems doubtful to get them to participate in that, but it's a good pointer to provide, and I'm at least glad that I now know about that list. So, thanks :)