Green-Sky/tomato
1
0
Fork 1
Code Issues Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

Merge commit '227425b90e9a671118026689dd30967e127a1090' as 'external/toxcore/c-toxcore'

Browse Source
This commit is contained in:
Green Sky
2023-07-25 11:53:09 +02:00
parent 310a099f14 227425b90e
commit 5568b70d31
467 changed files with 116591 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
external/toxcore/c-toxcore/docs/Hardening.txt vendored Normal file
View File

@ -0,0 +1,60 @@
Currently an attacker with sufficient resources could launch a large scale
denial of service type attack by flooding the Tox network with a bunch of nodes
that do not act like real nodes to prevent people from finding each other.
Due to the design of Tox, this is the worst thing an attacker can do to disrupt
the network.
This solution's goal is to make these denial of service attack very very hard
to accomplish.
For the network to work every Tox node must:
1. Respond to ping requests.
2. Respond to get node requests with the ids of nodes closest to a queried id
(It is assumed each nodes know at least the 32 nodes closest to them.)
3. Properly send crypto request packets to their intended destination.
Currently the only thing a node needs to do to be part of the network is
respond correctly to ping requests.
The only people we really trust on the network are the nodes in our friends
list.
The behavior of each Tox node is easily predictable. This means that it possible
for Tox nodes to test the nodes that they are connected to to see if they
behave like normal Tox nodes and only send nodes that are confirmed to behave
like real Tox nodes as part of send node replies when other nodes query them.
If correctly done, this means that to poison the network an attacker can only
infiltrate the network if his "fake" nodes behave exactly like real nodes
completely defeating the purpose of the attack. Of course nodes must be
rechecked regularly to defeat an attack where someone floods the network with
many good nodes then suddenly turns them all bad.
This also prevents someone from accidentally killing the tox network with a bad
implementation of the protocol.
Implementation ideas (In Progress):
1. Use our friends to check if the nodes in our close list are good.
EX: If our friend queries a node close to us and it correctly returns our
ip/port and then sends a crypto request packet to it and it routes it correctly
to us then it is good.
Problems with this: People don't always have at least one online friend.
2. Pick random nodes (add ourselves some random (fake) friends to increase the
pool of available nodes) and make then send requests to other nodes, the
response is then relayed back to us and compared to how the node should have
behaved. If the node is found to be behaving correctly, it is set as trusted.
Only trusted nodes are sent in send node packets, that is unless the exact node
being queried for in the getnode packet is present, it will be sent in the
sendnode packet even if it is not trusted.
The hypothesis is that if to be part of the network nodes have to behave
correctly it should prevent disruption from nodes that behave incorrectly.
(This idea is currently being implemented in the harden branch.)
...