tox_profile

Following up on: https://github.com/TokTok/c-toxcore/issues/419

I don't think indistinguishable message bytes and sizes are going to make any difference when they are sent over a network of so few bootstrap nodes. And anyone operating in a hostile environment is probably already running Tox over Tor, which works well.

Did the reports of blocking in China include blocking over Tor? Tor itself has implemented pluggable transport mechanisms that are continuously being improved, and these include ways to make the traffic look like another protocol like HTTP or whatever: https://snowflake.torproject.org/

So the best way to handle this may be to improve the documentation in Tox clients of how to use Tor. Whether or not you trust Tor (you can't trust exit nodes >25% of the time) it is the only thing that works right now in e.g. Egypt or Iran. And people can test the Tor setup with their brower (or TorBrowser) to make sure they are working before they try Tox over Tor.

The only way of getting a lot of resilience "cheaply" is to encourage bootstrap node operators to also run a Tor client to serve the node over Onionv3. This is the only way I can see dealing with the fact that Tox is a network of so few bootstrap nodes. If the Tox nodebase was improved to serve BS nodes, and OnionV3 relays, it would be much more resilient. I'm assuming the adversaries cannot block .onion addresses within Tor, which I think is a valid assumption for now.

There is a way of configuring a Tor client to uniquely assign a life-of-the-tor-instance IPv4 address from a predefined private range (VirtualAddrNetworkIPv4) to each onion address it sees: AutomapHostsOnResolve 1. So Tox could use OnionV3 BS nodes in a properly configured Tor with just some properly configured BS hosts lists (if enough BS nodes provided OnionV3 addresses). Then we could leave the heavy lifting of the cat-and-mouse games of pluggable transports etc. to Tor, and not try to chase them ourselves.

If you have such a list of onion addresses, the Tor user, who is running a Tor instance anyway to connect with the Tox client, adds this to the /etc/tor/torrc

VirtualAddrNetworkIPv4 172.16.0.0/12
AutomapHostsOnResolve 1

Then with the list of onion addresses for BS nodes that are running Tox as OnionV3, you can simply add aliases for the OnionV3 BS nodes directly into the /etc/torrc with the MapAddress command:

MapAddress  h5g52d26mmi67pzzln2uya5msfzjdewengefaj75diipeskoo252lnqd.onion 172.16.0.1

Orbot on Android supports the user adding custom lines to the torrc so you don't need to be rooted on Android.

Or you can use tor-resolve or tor-resolve -4 to get the good-for-you-only IP addresses of OnionV3 BS nodes in IPv4. So the Tox user does this, and then puts these addresses into his DHTnodes.json and boostraps his Tox client over Tor Onions . This works with libtoxcore is it is today, as long as your client doesn't suffer from the dreaded deranged-hard-coded-bs syndrome.

If we adopt a convention of putting a new onions field in the DHTnodes.json, this process could be automated by a simple Python script. The script could:

download the nodes file,
check for the location or onions field,
test the connection to the onion,
use tor-resolve to get the IPv4 address
add the address to the DHTnodes.json
repeat and rinse daily.

These steps would be automated by a simple bash or Python script, perhaps a Python script wrapped into an exe for Windows/Android. If you use MapAddress these mapped addresses are stable life of the Tor instance and the script would need rerunning when Tor is restarted. You can do the equivalent of tor-resolve in standard Python.

The best thing we can do is to make these instructions available with Tox downloads, and to ensure that all distributions of Tox come with the script on all platforms.

It's currently impossible to test as there is no equivalent to the other/fun/bootstrap_node_info.py script for TCP connections. For UDP you can send a packet of len 78 with the magic first bytes and get a version and MOTD reply. Not so for TCP (in fact if you do send such a packet to the TCP it send the BS node into an infinite loop for which it neverrecovers). So we need a simple fix to the TCP_server code to at least look for a special packet like this and be nice and send a simple nice reply like the UDP case. Raised as https://github.com/TokTok/c-toxcore/issues/2331

We should not kid ourselves that we don't all live in China or Iran - the planet is in a loc$down, and I think we might quickly find out just how much resiliance we need. s/China/Iran/Syria/Russia/GDR

PS: I doubt tor-resolve comes with OrBot and I doubt it comes with Tor on Windows or Torbrowser on Windows. We could ask the maintainers of TRIfA and aTOX to include it in their distributions, but if our script is in Python, we don't need it.

Up: DDosSmallNumberOfBSNodes

Up: Home