emdee/tox_profile
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Added tor

emdee 2022-10-27 06:56:21 +00:00
parent 92e4abd89f
commit afdf4486d4
5 changed files with 58 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Home.md

@ -25,8 +25,8 @@ wrinkles in the concepts.
* [[SecurityVulnerabilities]]: * [[SecurityVulnerabilities]]:
** [[UseGroupPasswordThroughAKDF]] * [[UseGroupPasswordThroughAKDF]]
** [[VulnerabilitiesInTheToxOnion]] * [[VulnerabilitiesInTheToxOnion]]
** [[DDosSmallNumberOfBSNodes]] * [[DDosSmallNumberOfBSNodes]]

4
MultiDeviceAnnouncementsPOC.md

@ -95,7 +95,9 @@ where:
Richer formats for the table are obviously possible, but we want to Richer formats for the table are obviously possible, but we want to
maintain a structure that foresees this table being managed by a maintain a structure that foresees this table being managed by a
keyring manager like ```keepassxc```. keyring manager like ```keepassxc```. For instance, this assumes
each "device" is only in Tox profile, whereas there could be more
than one device, hence keypair in use. We leave that aside for now.
## MultiDevice Announcements Push ## MultiDevice Announcements Push

7
SecurityVulnerabilities.md

@ -1,5 +1,10 @@
Previous: [[Home]] Previous: [[Home]]
> Regarding the general issue of "oh my god tox is not secure don't use it"
> this is slightly overreacting to the actual issues.
[426](https://github.com/TokTok/c-toxcore/issues/426)
* [[ToxHandshakeVulnerableToKCI]]
* [[UseGroupPasswordThroughAKDF]] * [[UseGroupPasswordThroughAKDF]]
* [[VulnerabilitiesInTheToxOnion]] * [[VulnerabilitiesInTheToxOnion]]
* [[DDosSmallNumberOfBSNodes]] * [[DDosSmallNumberOfBSNodes]]
@ -12,4 +17,4 @@ Previous: [[Home]]
See also: [[ToxComparedWithOtherIm]] See also: [[ToxComparedWithOtherIm]]
See also: <https://github.com/TokTok/c-toxcore/issues?q=is%3Aissue+is%3Aopen+label%3Asecurity> See also: <https://github.com/TokTok/c-toxcore/issues?q=is%3Aissue is%3Aopen label%3Asecurity>

62
ToxAndTorInChinaAndIran.md

@ -14,9 +14,12 @@ traffic look like another protocol like HTTP or whatever:
<https://snowflake.torproject.org/> <https://snowflake.torproject.org/>
So the best way to handle this may be to improve the documentation in 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). Tox of how to use Tor, and how to configure Tor to use pluggable
Whether or not you trust Tor (you can't trust Exit nodes 40% of the time) transports (obfs4). Whether or not you trust Tor (you can't trust
they are the only things that work right now in e.g. Egypt or Iran. 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 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 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 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. which I think is a valid assumption for now.
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
@ -43,41 +46,53 @@ VirtualAddrNetworkIPv4 172.16.0.0/12
AutomapHostsOnResolve 1 AutomapHostsOnResolve 1
``` ```
Then with the list of onion addresses for BS nodes that are running Tox as OnionV3, 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 Then the client running Tox over Tor can add aliases for each BS node directly
into your ```/etc/torrc``` with the ```MapAddress``` command 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 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 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 does this, and then puts these addresses into his ```DHTnodes.json```
Tox client over Tor Onions. This works with libtoxcore is it is today, as long as and boostraps his Tox client over Tor Onions . This works with
your client doesn't suffer from the dreaded deranged-hard-coded-bs syndrome. *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 If we adopt a convention of us using the location fields of the
Python script wrapped into an exe for Windows/Android. If you use MapAddress these DHTnodes.json, this process could be automated by a simple Python script.
mapped addresses are stable, and if you use ```tor-resolve```, these addresses are The script could:
good for life of the Tor instance and the script would need rerunning 1. download the nodes file,
when Tor is restarted. You can also get the IPv4 address of each Onion BS node, 2. check for the location field,
(for-life-of-the-tor-instance which is usually long enough) in 3. test the connection to the onion,
Python using the Tor stem library. 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 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 Tox downloads, and to ensure that all distributions of Tox come with
```tor-resolve``` on all platforms. I doubt it comes with tor-resolve and the script on all platforms. I doubt tor-resolve comes
[Orbot on Android](https://github.com/guardianproject/orbot/releases) with OrBot and I doubt it comes with
and I doubt it comes with [Tor](https://www.torproject.org/download/) or [Tor](https://www.torproject.org/download/) on Windows or
[Torbrowser on Windows](https://www.torproject.org/download/). [Torbrowser on Windows](https://www.torproject.org/download/).
We could ask the maintainers of We could ask the maintainers of
[TRIfA](https://f-droid.org/en/packages/com.zoffcc.applications.trifa/) and [TRIfA](https://f-droid.org/en/packages/com.zoffcc.applications.trifa/) and
[aTOX](https://f-droid.org/en/packages/ltd.evilcorp.atox) to include [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 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. of ```tor-resolve``` for our packages to make sure it is available to our
It's a static utility that rarely changes. 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. 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 (in fact if you do send such a packet 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 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 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 - 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 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 how much resiliance we need. s/China/Iran/Syria/Russia/GDR

8
VulnerabilitiesInTheToxOnion.md

@ -6,4 +6,10 @@ Known vulnerabilities in the tox onion:
* <https://github.com//zugz/tox-onionPathsProposal/blob/master/onionVulns.md> * <https://github.com//zugz/tox-onionPathsProposal/blob/master/onionVulns.md>
* <https://github.com/TokTok/c-toxcore/issues/1121> * <https://github.com/TokTok/c-toxcore/issues/1121>
[algor1th](https://github.com/algor1th) created a formal model that shows that announcements are linkable, and note trace equivalent to searches. It can be found at https://github.com/algor1th/tox-verification/blob/master/dht.dps. Linkability here means that a public key of a node can be linked to it's ip adress when announcing. [algor1th](https://github.com/algor1th) created a formal model that
shows that announcements are linkable, and note trace equivalent to
searches. It can be found at
https://github.com/algor1th/tox-verification/blob/master/dht.dps.
Linkability here means that a public key of a node can be linked to
it's ip adress when announcing.