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

UpdateTor

emdee 2022-10-28 19:46:25 +00:00
parent d62f1d6bf2
commit dc5f8688ef
2 changed files with 70 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
AddingAnOnionService.md

@ -6,16 +6,16 @@ is vulnerable to being completely taken down by blocking a small
number of nodes. This is already happening in places like Iran.
It would help if all the BS node operators could also run a Tor client
(not exit node), in addition to running their node. There are no risks
to the BS operator from running a Tor client in any country that Tor
is still legal as it's 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.
The BS service is on the opennet anyway so an onion is just another
access method. So we get dozens of Tor onion nodes running quickly,
we could test out running Tox *in* Tor using Hidden Services. If the
Tox nodebase was improved to serve BS nodes, 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.
(not exit node), in addition to running their node. There should be no
risks from running a Tor client as it's 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. The BS service is on the opennet anyway
so an onion is just another access method. So we get dozens of Tor
onion nodes running quickly, we could test out running Tox *in* Tor
using Hidden Services. If the Tox nodebase was improved to serve BS
nodes, 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 are [simple instructions](https://community.torproject.org/onion-services/setup/)
to get Tor up and running, and it's distributed in all Linux distributions.
@ -52,25 +52,25 @@ and post it along with your node's public key to the
## Using an Onion Bootstrap node
To let your client know that you have an onion node it can user,
you need to add the onion address to your DHTnode.json file.
But Tox clients don't understand onion addresses and until they do,
we do the following:
1. Get the IP address your Tor assigns to the onion address
1. Get the IP address your Tor assigns to the onion address:
```
tor-resolve -4 l2ct3xnuaiwwtoybtn46qp2av4ndxcguwupzyv6xrsmnwi647vvmwtqd.onion
```
It will reply with an IPv4 address starting with ```172.```.
You'll need the pubkic key of your BS server. Take that address and
add to the DHTnodes.json file in the list of ```nodes```.
2. You'll need the pubkic key of your BS server. Take that address and
add to the DHTnodes.json file as a new dictionary in the list of ```nodes```.
If your nodes file is line one line you can pretty it up with the
If your nodes file is one long line you can pretty it up with the
jq utility: ```jq . < DHTnodes.json > Prettynodes.json```.
Put the address in the ```ipv4``` slot and the
Make a new entry at the beginning of the nodes list: after the ```[```
and followed by a ```,``` - put the address in the ```ipv4``` slot and the
port in the tcp_ports list and put the onion address as the location.
```
{"last_scan": 1665034198,
@ -97,14 +97,15 @@ port in the tcp_ports list and put the onion address as the location.
},
```
You can also add this pair to the onions slot in your entry in the
DHTnodes.json file. If there is not an onions slot, create one.
You can copy the above and add the onion:port pair to the onions slot
and update the rest of the fields.
### Updating
This IP address changes each time Tor restarts, so each time Tor
restarts the DHTnodes.json file needs updating. You can assign it
a permanent IP address by using the MapAddress line in the torrc:
restarts ipv4 field of you entry in the DHTnodes.json file needs updating.
You can assign it a permanent IP address by using the MapAddress line
in the torrc:
```
MapAddress l2ct3xnuaiwwtoybtn46qp2av4ndxcguwupzyv6xrsmnwi647vvmwtqd.onion 10.192.0.1
```
@ -114,10 +115,24 @@ You can use any address in the range defined by
VirtualAddrNetworkV4 10.192.0.0/10
```
These addresses will be permanent and will not change with Tor restarts.
You can similarly add all the Tox onions you know about in this manner.
We can work on a script that automates this.
We can work on a script that automates this, and a way of publishing
onions in the mailing list or an NGC group.
### Client Side
A person that is already using Tor as a client, and Tox over Tor,
only needs to add the first section in the ```/etc/tor/torrc```
described above, and the MapAddress lines. We could have our update
utility read the DHTnodes file and look for onions slot, and
print out the MapAddress lines to be added to the ```torrc```.
Then they'll be using Tox *in* Tor with no vulnerabilities to the
BS node being blocked, or vulnerabilities at exit nodes.
Details:
* https://git.plastiras.org/emdee/tox_profile/ToxAndTorInChinaAndIran
* https://community.torproject.org/onion-services/setup/
* https://community.torproject.org/onion-services/
* https://www.wired.com/story/tor-browser-russia-blocks/

70
ToxAndTorInChinaAndIran.md

@ -1,6 +1,6 @@
Up: [[Home]]
From: https://github.com/TokTok/c-toxcore/issues/419
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.
@ -14,20 +14,19 @@ 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. And people can test the Tor setup with
their brower (or TorBrowser) to make sure they are working before
they try Tox over Tor.
Tox clients of how to use Tor. Whether or not you trust Tor
(you can't trust exit nodes 40% 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.
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
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 for now.
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
@ -40,22 +39,21 @@ the heavy lifting of the
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```
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```.
Then the client running Tox over Tor can add aliases for each BS node directly
into your ```/etc/torrc``` with the ```MapAddress``` command
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](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.
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
@ -64,13 +62,12 @@ 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 us using the location fields of the
DHTnodes.json, this process could be automated by a simple Python script.
The script could:
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:
1. download the nodes file,
2. check for the location field,
2. check for the location or onions field,
3. test the connection to the onion,
4. use tor-resolve or the Python stem library to get the IPv4 address
4. use tor-resolve to get the IPv4 address
5. add the address to the DHTnodes.json
6. repeat and rinse daily.
@ -78,19 +75,11 @@ 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
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 just a standalone static utility that rarely changes.
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.
@ -102,7 +91,6 @@ 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
@ -112,5 +100,13 @@ how much resiliance we need. s/China/Iran/Syria/Russia/GDR
* https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook
* https://www.lifesitenews.com/news/biden-executive-order-allows-spying-on-americans-to-assess-political-instability-climate-threats/
PS: 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, but if our script is in Python, we don't need it.
Up: [[DDosSmallNumberOfBSNodes]]