emdee/tox_profile
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

DDosSmallNumberOfBSNodes.md

emdee 2022-10-12 22:17:57 +00:00
parent d3c6249463
commit 9f416f9cdc
2 changed files with 56 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
DDosSmallNumberOfBSNodes.md

@ -1,10 +1,59 @@
Previous: [[SecurityVulnerabilities]]
By design, Tox relies on a small number of BS nodes.
By design, Tox relies on a small number of BS nodes. As the network
is now, the number of nodes is very small, and all well known. So Tox
is vulnerable to being completely taken down by blocking a small
number of nodes.
The same problem, to a lesser extent affects Tor, although they have a
few thousand nodes. Doing the best we can with what we have, we can
take advantage of something from libtoxcore: the ```tcp_server slot```.
It is supported by most clients like toxic or toxygen.
So this is what is proposed:
1. Fix libtoxcore to be able to accept .onion addresses for BS nodes,
or test the workarounds: see [[ToxAndTorInChinaAndIran]].
2. All BS node operators are asked to also run a Tor client (not exit node),
in addition to running their node. We put together easy-to-follow instructions
on how to download/configure/run Tor. There are no risks to the BS operator
from running a Tor client (not exit node), and the overhead in negligible.
The onion server is a 127.0.0.1 service, so cannot be seen by your ISP.
Your service is on the opennet anyway so an onion is just another access method.
So we get dozens of Tor onion nodes running quickly.
3. All Tor Tox client users are asked to also configure their Tox client to
use ```--tcp_server``` with a random port, and configure their Tor client
(not exit node) to provide that ```tcp_server``` as an onion accessible relay,
in addition to running the normal Tor. We put together easy-to-follow
instructions on how to configure Tor to serve that ```tcp_server``` as an onion.
There are no risks to the user as he's already running a Tor client
(not exit node), and the overhead in the Tox client in negligible.
The tcp_server is a 127.0.0.1 service, so cannot be seen by your ISP.
So we get a tcp_server extra for every Tor user. That scales well.
4. Modify Tox clients to detect if they are behind Tor and on their homepage
or splash screen ask them to run a ```tcp_server```.
5. Improve the client documentation on how to run Tox over Tor,
particularly for Android users: how to download Orbot from
<https://f-droid.org> (preferred over Srewgle Play) and configure them.
Tell them to try first running Orbot and a browser that works with it,
and test out if their mobile to see if they can run Tor. The Tor devs are actively
playing cat and mouse with Iran and have other tricks if regular Tor fails.
6. Improve our ability to monitor network performance, including TCP relays,
so we can detect if anyone is attacking the network.
PS: Trying make it easy to package and run a BS node in places like
Iran is going about it in the wrong way; I doubt running a BS node in
Iran is healthy thing to do. Get them onto Tor, and improve service over Tor.
Much better to get all of our BS nodes to run an onion service so
there is good availability and redundancy, and fix the minor problems
needed for Tox to work with onion BS nodes.
As the network is now, the number of nodes is very small, and all well known.
So Tox is vulnerable to being completely taken down by blocking a
small number of nodes.
See: [[ToxAndTorInChinaAndIran]]

3
GroupOfDevicesPOC.md

@ -7,5 +7,6 @@ One way to address the multi-device problem is to add the multiple devices of a
It may not scale well because messaging is sent to all devices of all users;
a single active user approach would be more efficient.
And it wouldn't work for groups very well as a group-of-devices can not be a member of an NGC group.
And it wouldn't work for groups very well as a group-of-devices can
not be a member of an NGC group.