UpdateTor
parent
d62f1d6bf2
commit
dc5f8688ef
@ -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/
|
||||
|
@ -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.
|
||||
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
|
||||
@ -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]]
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user