|
|
|
@ -14,9 +14,12 @@ 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 (obfs4).
|
|
|
|
|
Whether or not you trust Tor (you can't trust Exit nodes 40% of the time)
|
|
|
|
|
they are the only things that work right now in e.g. Egypt or Iran.
|
|
|
|
|
Tox of how to use Tor, and how to configure Tor to use pluggable
|
|
|
|
|
transports (obfs4). Whether or not you trust Tor (you can't trust
|
|
|
|
|
Exit nodes 40% of the time) they are the only things that work 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.
|
|
|
|
|
|
|
|
|
|
I also think the only way of getting a lot of resilience "cheaply" is
|
|
|
|
|
to encourage bootstrap node operators to also run a Tor client to serve
|
|
|
|
@ -24,7 +27,7 @@ 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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
@ -43,41 +46,53 @@ 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 torrc.
|
|
|
|
|
you can simply add aliases for the OnionV3 BS nodes directly into the
|
|
|
|
|
```/etc/torrc```.
|
|
|
|
|
Then the client running Tox over Tor can add aliases for each BS node directly
|
|
|
|
|
into your ```/etc/torrc``` with the ```MapAddress``` command
|
|
|
|
|
```
|
|
|
|
|
MapAddress onion1.tox.xyz h5g52d26mmi67pzzln2uya5msfzjdewengefaj75diipeskoo252lnqd.onion
|
|
|
|
|
MapAddress h5g52d26mmi67pzzln2uya5msfzjdewengefaj75diipeskoo252lnqd.onion 172.16.0.1
|
|
|
|
|
```
|
|
|
|
|
The domainname you map to does not have to be real, and should not exist.
|
|
|
|
|
[Orbot on Android](https://github.com/guardianproject/orbot/releases)
|
|
|
|
|
supports the user adding custom lines to the ```torrc``` so you don't
|
|
|
|
|
need to be routed 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.
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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, and if you use ```tor-resolve```, these addresses are
|
|
|
|
|
good for life of the Tor instance and the script would need rerunning
|
|
|
|
|
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) in
|
|
|
|
|
Python using the Tor stem library.
|
|
|
|
|
If we adopt a convention of us using the location fields of the
|
|
|
|
|
DHTnodes.json, this process could be automated by a simple Python script.
|
|
|
|
|
The script could:
|
|
|
|
|
1. download the nodes file,
|
|
|
|
|
2. check for the location field,
|
|
|
|
|
3. test the connection to the onion,
|
|
|
|
|
4. use tor-resolve or the Python stem library to get the IPv4 address
|
|
|
|
|
5. add the address to the DHTnodes.json
|
|
|
|
|
6. 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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
tor-resolve and the script on all platforms. I doubt tor-resolve comes
|
|
|
|
|
with OrBot and I doubt it comes with
|
|
|
|
|
[Tor](https://www.torproject.org/download/) on Windows 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.
|
|
|
|
|
of ```tor-resolve``` for our packages to make sure it is available to our
|
|
|
|
|
users. It's just a standalone static utility that rarely changes.
|
|
|
|
|
|
|
|
|
|
I've tried this but it's currently impossible to test as there is no equivalent
|
|
|
|
|
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
|
|
|
|
@ -87,6 +102,7 @@ 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
|
|
|
|
|