emdee/tox_profile
2
3
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update 'ToxAndTorInChina'

emdee 2022-09-26 09:52:00 +02:00
parent 70929962f6
commit e8d4d2f063
1 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
ToxAndTorInChina.md Normal file

@ -0,0 +1,20 @@
FromL 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 of how to use Tor, and how to configure Tor to use pluggable transports. They are the only things that work in e.g. Egypt or Iran.
I also think the other way of getting a lot of resilience "cheaply" is to encourage bootstrap node operators to also run a Tor node to serve the BS 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 codebase was improved to work with Onionv3 BS nodes, and OnionV3 relays, it would be much more resilient.
There is a way of configuring Tor to uniquely assign a life-of-the-tor-instance IPv4 address from a predefined private range (VirtualAddrNetwork) to each onion address it sees: AutomapHostsOnResolve. 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 (or i2p), and not try to chase them ourselves.
To even try out this approach I think you need to fix the [open-for-five-years-and-counting](https://github.com/TokTok/c-toxcore/issues/469) issue of not resolving the IP address of the targets when you are in front of a SOCKS5 proxy (Tor). But maybe there's another way: you could contact each of the OnionV3 BS nodes outside of Tox and get the IPv4 address of each Onion BS node in Python using the Tor stem library. Then you could use these IPv4 addresses as your BS nodes, as long as your client didn't suffer from deranged-hard-coded-bs syndrome.
I've tried this but 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 never recovers). 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.
We should not kid ourselves that we don't all live in China - all it will take is one NGC group dedicated to the trending topic of SuddenDeath and I think we might find just how much resiliance we need.
https://github.com/TokTok/c-toxcore/issues/419