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

Tox over Tor

emdee 2022-10-15 10:21:23 +00:00
parent 1b956831db
commit 146a54ff7e
13 changed files with 1003 additions and 988 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
ToxAndTorInChinaAndIran.md

@ -5,10 +5,10 @@ From: https://github.com/TokTok/c-toxcore/issues/419
I don't think indistinguishable message bytes and sizes are going to 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. 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 And anyone operating in a hostile environment is probably already
running Tox over Tor, which works well. running Tox over [Tor](https://www.torproject.org/download), which works well.
Did the reports of blocking in China include blocking over Tor? Tor Did the reports of blocking in China include blocking over Tor?
itself has implemented pluggable transport mechanisms that are Tor itself has implemented pluggable transport mechanisms that are
continuously being improved, and these include ways to make the continuously being improved, and these include ways to make the
traffic look like another protocol like HTTP or whatever: traffic look like another protocol like HTTP or whatever:
<https://snowflake.torproject.org/> <https://snowflake.torproject.org/>
@ -23,7 +23,8 @@ to encourage bootstrap node operators to also run a Tor client to serve
the BS node over Onionv3. This is the only way I can see dealing with the the BS 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 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. 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. I'm assuming the adversaries cannot block .onion addresses within Tor,
which I think is a valid assumption.
There is a way of configuring a Tor client to uniquely assign a 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 life-of-the-tor-instance IPv4 address from a predefined private range
@ -31,12 +32,12 @@ life-of-the-tor-instance IPv4 address from a predefined private range
```AutomapHostsOnResolve 1```. So Tox could use OnionV3 BS nodes in a ```AutomapHostsOnResolve 1```. So Tox could use OnionV3 BS nodes in a
properly configured Tor with just some properly configured BS hosts lists properly configured Tor with just some properly configured BS hosts lists
(if enough BS nodes provided OnionV3 addresses). Then we could leave (if enough BS nodes provided OnionV3 addresses). Then we could leave
the heavy lifting of the cat-and-mouse games of pluggable transports etc. the heavy lifting of the
to Tor (or i2p), and not try to chase them ourselves. [cat-and-mouse games](https://github.com/guardianproject/orbot/issues/742)
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 If you have such a list of onion addresses, the Tor user, who is running a Tor
a Tor instance anyway to connect with the Tox client, adds this to the instance anyway to connect with the Tox client, adds this to the ```/etc/tor/torrc```
```/etc/tor/torrc```
``` ```
VirtualAddrNetworkIPv4 172.16.0.0/12 VirtualAddrNetworkIPv4 172.16.0.0/12
AutomapHostsOnResolve 1 AutomapHostsOnResolve 1
@ -48,18 +49,31 @@ does this and puts these addresses into his ```DHTnodes.json``` and boostraps hi
Tox client over Tor Onions. This works with libtoxcore is it is today, as long as 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. your client doesn't suffer from the dreaded deranged-hard-coded-bs syndrome.
These steps would be automated by a simple bash or Python script, These steps would be automated by a simple bash or Python script, perhaps a
perhaps a Python script wrapped into an exe for Windows. These addresses are Python script wrapped into an exe for Windows/Android. These addresses are
good for life of the Tor instance, and the script would need rerunning when Tor good for life of the Tor instance, and the script would need rerunning
is restarted. You can also get the IPv4 address of each Onion BS node, when Tor is restarted. You can also get the IPv4 address of each Onion BS node,
(for-life-of-the-tor-instance which is usually long enough) (for-life-of-the-tor-instance which is usually long enough) in
in Python using the Tor stem library. Python using the Tor stem library.
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
```tor-resolve``` on all platforms. I doubt it comes with
[Orbot on Android](https://github.com/guardianproject/orbot/releases)
and I doubt it comes with [Tor](https://www.torproject.org/download/) or
[Torbrowser on Windows](https://www.torproject.org/download/).
We could ask the maintainers of
[TRIfA](https://f-droid.org/en/packages/com.zoffcc.applications.trifa/) and
[aTOX](https://f-droid.org/en/packages/ltd.evilcorp.atox) to include
it in their distributions, and it would be simple for us to compile a version
of ```tor-resolve``` for our packages to make sure it is available to our users.
It's a static utility that rarely changes.
I've tried this but it's currently impossible to test as there is no equivalent 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. 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 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 ( version and MOTD reply. Not so for TCP (in fact if you do send such a packet
in fact if you do send such a packet to the TCP it send the BS node into an to the TCP it send the BS node into an
[infinite loop for which it neverrecovers](https://github.com/TokTok/c-toxcore/issues/2332)). [infinite loop for which it neverrecovers](https://github.com/TokTok/c-toxcore/issues/2332)).
So we need a simple fix to the TCP_server code to at least look for a 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 special packet like this and be nice and send a simple nice reply like
@ -75,3 +89,4 @@ how much resiliance we need. s/China/Iran/Syria/Russia/GDR
* https://www.lifesitenews.com/news/biden-executive-order-allows-spying-on-americans-to-assess-political-instability-climate-threats/ * https://www.lifesitenews.com/news/biden-executive-order-allows-spying-on-americans-to-assess-political-instability-climate-threats/
Up: [[DDosSmallNumberOfBSNodes]] Up: [[DDosSmallNumberOfBSNodes]]

2
ToxNetworkResilience.md

@ -32,7 +32,7 @@ configuration:
# Tox hidden service configuration. # Tox hidden service configuration.
HiddenServiceDir /var/lib/tor/tox-hsv3/ HiddenServiceDir /var/lib/tor/tox-hsv3/
HiddenServicePort 3389 127.0.0.1:3389 HiddenServicePort 3389 127.0.0.1:3389
HiddenServicePort 3389 127.0.0.1:33446 HiddenServicePort 33446 127.0.0.1:33446
``` ```
assuming your Tor lib directory os ```/var/lib/tor```. In that subdirectory assuming your Tor lib directory os ```/var/lib/tor```. In that subdirectory
you will find a file named ```hostname``` which is the ```.onion``` name you will find a file named ```hostname``` which is the ```.onion``` name