emdee
/
tox_profile
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Page: DDosSmallNumberOfBSNodes
Pages
AddingAnOnionService DDosSmallNumberOfBSNodes GroupOfDevicesPOC Home MultiDevice Announcements POC MultiDeviceAnnouncementsPOC QToxGreen SecurityVulnerabilities ToxAndTorInChinaAndIran ToxComparedWithOtherIm ToxHandshakeVulnerableToKCI ToxMultiDevice ToxNetworkResilience Toxygen ToxygenWeechat UseGroupPasswordThroughAKDF VulnerabilitiesInTheToxOnion
7 DDosSmallNumberOfBSNodes
emdee edited this page 2022-10-15 10:21:23 +00:00

Previous: SecurityVulnerabilities

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.

Up: Home