[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Bad Exit Node Control
On Sat, Mar 30, 2013 at 2:44 AM, Roc Admin <onionroutor@xxxxxxxxx> wrote:
> I'm working on an updated version of SnakesOnATor (SOAT) that was used
> to monitor the Tor network for bad exit nodes.
Great! Is the source available anywhere?
> This is a similar
> function to InspectTor hosted on a .onion site but that page owner has
> not been reachable and has not reached out to other Tor folk.
> The main problem with InspecTor is that he/she is recommending that
> because a bad exit node has been detected, users should change their
> Tor configs to never use those nodes. This would eventually negatively
> affect a user's anonymity as they would create a network fingerprint
> unlike any others.
It would be great if the operator of this service provided
instructions for replicating their results, so that other volunteers
can help out. Getting multiple independent reporters is a big step
towards automating BadExit policies.
> But this is, AFAIK, going to be the same problem that SOAT or any
> future solution would have. Namely, that there is no official
> mechanism to kick off a bad exit. If I understand correctly, this was
> a manual process in the past that entailed emailing the op and
> eventually kicking them off?
There is no existing automated mechanism for giving an exit the
BadExit flag, SOAT reports and independent reports get emailed to a
list where a directory authority operator or a volunteer could
manually review the reports before manually adding a BadExit line to
the directory authority's torrc.
There is a proposal for an automated mechanism in:
Section: 3. Automatic BadExit Marking
> I'm looking for feedback on the above statements. Maybe I'm missing
> something or do not know about the underlyings of the process.
> If I do understand it correctly, I wonder if a solution is necessary
> that integrates monitoring and removing bad exit nodes and malicious
> activity, If we agree that users should not change their routes, then
> routes should be changed on a global level to remove bad exits by an
> authoritative party. Such a solution would be a challenge to say the
> least because what stops a bad Op from spinning up a new node. Maybe
> this is the reason we haven't done this in the past.
That's just the beginning of the fun. It's a big project, that could
use attention. Have you thought about how such a system might be
designed, or other concerns?
> tor-talk mailing list
tor-talk mailing list