![]() In the latter case, the node may be marked as a BadExit if a scanner detects that it intentionally blocked a connection that it offered to relay.Ī node in an earlier position in a circuit can't know the ultimate destination of the circuit, or the content exchanged over it, although it could in theory blacklist individual nodes as a next hop (which doesn't typically really accomplish anything for content-blocking purposes, and could also be detected if it were a pervasive practice). Tor has changed its path selection algorithms a bit based on ideas from these papers.Ī Tor exit node can block destinations openly by declaring limitations in its exit policy (in principle by IP address or port, although I don't know if any exit policies use IP address this way) or by simply firewalling connections from itself to particular destinations. 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). 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.īy 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.ĭetermining 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. In that case, there wouldn't be a way to easily infer that these nodes are associated with the same operator.Īs someone has said elsewhere in this thread, there's still the hope that if different organizations add network capacity with malicious intent, they tend to undermine one another's chances of succeeding, at least as long as they aren't directly colluding (because the basic security goal in Tor is that clients choose paths whose constituent relays don't share information with one another). However, a sufficiently malicious attacker could add a lot of network capacity in a way that isn't recognizably associated as belonging to the same entity, for example by adding nodes in different data centers, with different speeds, with different software environments, and not all coming online at the same moment. In this case, the relays can be given a flag like BadExit by the Tor developers, which will stop any Tor client from selecting those relays as exit nodes in a path. A common example is a large number of new relays that appear within a short period of time with similar characteristics and don't declare common ownership.Įdit: one of the main tools for this is OrNetRadar, which seems to primarily use the autonomous system number in which the relays are located, as well as the timing of their creation: Some people in the Tor community try to watch for relay-creation behavior that they consider suspicious. Of course, a malicious relay operator that wanted to increase its chances of being used as both the entry and exit nodes in a single path (and thereby easily being able to correlate traffic between its origin and destination) could add a lot of nodes and not own up to their relationship. The Tor Project tells relay operaters to set a value called MyFamily to declare which relays are run by the same person or group, so that Tor users won't use more than one relay in the same path with the same operator.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |