3 ms·
It seems like I can query BadExit status (which of course makes sense, as the client wants to avoid bad exits) so that makes it a bit useless as a protection me
by kriro 7y ago
It seems like I can query BadExit status (which of course makes sense, as the client wants to avoid bad exits) so that makes it a bit useless as a protection mechanism against determined malicious agents that operate at scale. In fact it makes it quite easy to set up some experiments to find the best ways to circumvent this.
Experiment A: fire up a baunch of nodes one way, see how many are marked as BadExit; experiment B: vary the way you fire up on one variable (time-delay, node server Os etc.), measure, repeat
- schoen 7y agoTrue. In fact, many of the discussions within the Tor community related to detection of colluding nodes even happen in public, so you could observe them on mailing lists and try not to repeat your mistake! This mechanism is very fragile. By contrast, being marked as a BadExit due to tampering with content can be due to tests whose exact nature isn't disclosed and changes over time, and it doesn't happen instantly, so it might be hard for an individual deliberately malicious exit to deduce which action it took that resulted in the BadExit flag. Determining whether nodes are secretly colluding (or, equivalently for some purposes, whether their communications can be closely observed by the same adversary!) is a mostly unsolvable problem, and that's an important limitation for Tor's security. There have been some papers that do a statistical analysis about the probability of an individual adversary winning against an individual user, given some assumptions about that adversary's capabilities (what fraction of nodes the adversary controls or observes). Tor has changed its path selection algorithms a bit based on ideas from these papers.