Open nazar-pc opened 7 years ago
The issue
Currently when constructing onion path through 3 nodes, the middle node can scan previous and next node for known peers, take own known peers and the intersection of these 3 sets will very likely contain the node that have constructed onion path.
Could you explain this in more detail? In particular, what do you mean by "scan previous and next node for known peers"?
In particular, what do you mean by "scan previous and next node for known peers"?
In DHT we query our peers recursively to get the information we need (like address of node with particular ID).
Using nodes discovered during DHT operation for onion path means that we either contacted each of those nodes directly or contacted their direct neighbors.
With this knowledge we can assume that whenever someone constructs onion path through our machine, then there is a high change that this someone have recently contacted us directly as well as the node before and after us in onion path (we know where request came from and where it goes next). By querying previous and next node in onion path for their peers we can collect enough information to figure our who is that someone.
Aha, I see what you mean. Yes, this is something of a problem with the current implementation. But taking the nodes we use for onion paths from the DHT is a bad idea anyway. For example, if the third ("exit") node in the path is one we've connected to directly in the DHT, then they have seen our IP address and so may be able to link our request to our IP address.
Please see TokTok/c-toxcore#596. This issue is discussed a little more there. It would be great to hear your thoughts on that proposal.
You have a high chance of asking your friends to be an onion node for you. So if you're able to trust your friends, and have a large list of online friends. You're likely to have a better than average onion route.
That said: There are additional issues with using the onion. The original use case of the onion doesn't match the use case for Tox. As such, the security granted by the the TOR onion, isn't gained by the Tox onion.
@zugz, your linked issue describes more sophisticated approach and to slightly different issue, but interesting anyway, since involves details about actual Tox implementation (which I'm not familiar with).
@GrayHatter, I understand that Tox is not considered to offer anonymity, but being able to easily figure out who is connecting to whom still leaks too much information in my opinion. It makes targeted DoS possible easily as well as allows to collect useful metadata about established connections.
I'm working on something that is like Tox, but works in different environment and with slightly different properties. So this issue is primarily for myself to better understand how Tox works under the hood and to check whether my concerns are real.
Part of the reason the onion exists is to offer some level of anonymity. The fact that the onion doesn't is a bug.
On Sep 18, 2017 19:35, "Nazar Mokrynskyi" notifications@github.com wrote:
@zugz https://github.com/zugz, your linked issue describes more sophisticated approach and to slightly different issue, but interesting anyway, since involves details about actual Tox implementation (which I'm not familiar with).
@GrayHatter https://github.com/grayhatter, I understand that Tox is not considered to offer anonymity, but being able to easily figure out who is connecting to whom still leaks too much information in my opinion. It makes targeted DoS possible easily as well as allows to collect useful metadata about established connections.
I'm working on something that is like Tox, but works in different environment and with slightly different properties. So this issue is primarily for myself to better understand how Tox works under the hood and to check whether my concerns are real.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TokTok/spec/issues/61#issuecomment-330410992, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO20KqPuJ4ORc0jvxgC3TtK3G5a-JhTks5sjyhUgaJpZM4Pacff .
You have a high chance of asking your friends to be an onion node for you.
I don't think that's true with the current implementation. Unless you mean in TCP-only mode and when your friends are running TCP servers?
I've been researching this related topics for a while and I have a concern regarding the onion path construction. Kind of related to #56, but from a different angle.
Background
If I understand it correctly, Tor's onion proxy uses directories to fetch random slice of onion routers for building its circuits. This is their way to avoid connecting to nodes directly, but those directory nodes are considered trusted. In Tox there are no such nodes by design (bootstrap nodes are trusted to some degree though, but they are a bit different) and everything is connected directly, which can be used to figure out who have constructed onion path (if my understanding of current Tox's behavior is correct).
The issue
Currently when constructing onion path through 3 nodes, the middle node can scan previous and next node for known peers, take own known peers and the intersection of these 3 sets will very likely contain the node that have constructed onion path.
Potential hardening
I think it could be a good idea to have a dedicated method in DHT for fetching information about all the known nodes (not just search for some of them, but literally all known nodes). Then, by collecting a lot of nodes in this way, filter out those which we've connected to recently and only after that select potential candidates for onion path.
When we select second and third node that we've never connected before (or at least recently), it would mean that middle node will have to collect information about known peers of known peers, namely one step deeper. Assuming that the first node in onion path (that we should be connected directly) has enough known nodes (can be made a requirement for such a node), this makes an intersection of potential candidates bigger. How much bigger and whether that is statistically enough is an open question.