Added tor
parent
92e4abd89f
commit
afdf4486d4
6
Home.md
6
Home.md
@ -25,8 +25,8 @@ wrinkles in the concepts.
|
||||
|
||||
* [[SecurityVulnerabilities]]:
|
||||
|
||||
** [[UseGroupPasswordThroughAKDF]]
|
||||
** [[VulnerabilitiesInTheToxOnion]]
|
||||
** [[DDosSmallNumberOfBSNodes]]
|
||||
* [[UseGroupPasswordThroughAKDF]]
|
||||
* [[VulnerabilitiesInTheToxOnion]]
|
||||
* [[DDosSmallNumberOfBSNodes]]
|
||||
|
||||
|
||||
|
@ -95,7 +95,9 @@ where:
|
||||
|
||||
Richer formats for the table are obviously possible, but we want to
|
||||
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
|
||||
|
||||
|
@ -1,5 +1,10 @@
|
||||
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]]
|
||||
* [[VulnerabilitiesInTheToxOnion]]
|
||||
* [[DDosSmallNumberOfBSNodes]]
|
||||
@ -12,4 +17,4 @@ Previous: [[Home]]
|
||||
|
||||
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>
|
||||
|
@ -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
|
||||
|
@ -6,4 +6,10 @@ Known vulnerabilities in the tox onion:
|
||||
* <https://github.com//zugz/tox-onionPathsProposal/blob/master/onionVulns.md>
|
||||
* <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.
|
||||
|
Loading…
Reference in New Issue
Block a user