From 550cfdb17200047b10c9958eab970914cdfc69b4 Mon Sep 17 00:00:00 2001 From: emdee Date: Tue, 11 Oct 2022 10:10:20 +0000 Subject: [PATCH] Added ToxNetworkResilience.md --- Home.md | 34 +++++++++++++++++----------- MultiDeviceAnnouncementsPOC.md | 4 ++-- QToxGreen.md | 16 ++++++------- SecurityVulnerabilities.md | 2 +- ToxComparedWithOtherIm.md | 2 +- ToxMultiDevice.md | 20 ++++++++--------- ToxNetworkResilience.md | 41 ++++++++++++++++++++++++++++++++++ 7 files changed, 84 insertions(+), 35 deletions(-) create mode 100644 ToxNetworkResilience.md diff --git a/Home.md b/Home.md index 1a66065..1fe2199 100644 --- a/Home.md +++ b/Home.md @@ -1,24 +1,32 @@ # Welcome to the Wiki. -What I am noticing is that there is no notion of a Tox Improvement Proposal(TIP), -so ideas and vulnerabilities get forgotten in abandonned PRs in abandoned repos. +What I am noticing is that there is no notion of a Tox Improvement +Proposal(TIP), so ideas and vulnerabilities get forgotten in +abandonned PRs in abandoned repos, or ignored issues. -I suggested wiki.tox.chat as a place to identify and prioritize TIPs but maybe we can elaborate POCs here. I want to "argue" it out to get to the "best" proposal so work so work can get going on a trial version. developers who know the key exchange mechanisms can bring a lot of the existing codebase to bear on this problem, and resolve wrinkles in the concepts. +I suggested wiki.tox.chat as a place to identify and prioritize TIPs +but maybe we can elaborate POCs here. I want to "argue" it out to get +to the "best" proposal so work so work can get going on a trial +version. developers who know the key exchange mechanisms can bring a +lot of the existing codebase to bear on this problem, and resolve +wrinkles in the concepts. ### Multi-Device DHT announcements: * [[MultiDevice Announcements POC]] - -### Group-of-devices: * [[GroupOfDevicesPOC]] +* Original TokTok ToxMultiDevice: [[ToxMultiDevice]] -### Original TokTok ToxMultiDevice: -* [[ToxMultiDevice]] - - -### [[SecurityVulnerabilities]]: -* [[UseGroupPasswordThroughAKDF]] -* [[VulnerabilitiesInTheToxOnion]] -* [[DDosSmallNumberOfBSNodes]] +### Network Resilience + +* [[ToxNetworkResilience]] + +### Security + +* [[SecurityVulnerabilities]]: + +** [[UseGroupPasswordThroughAKDF]] +** [[VulnerabilitiesInTheToxOnion]] +** [[DDosSmallNumberOfBSNodes]] diff --git a/MultiDeviceAnnouncementsPOC.md b/MultiDeviceAnnouncementsPOC.md index 5b185ef..7a56885 100644 --- a/MultiDeviceAnnouncementsPOC.md +++ b/MultiDeviceAnnouncementsPOC.md @@ -7,7 +7,7 @@ usage of Tox with multiple devices is an urgent problem, as anyone with mobiles runs into it, and all the competition software deals with it. MultiDevice is much easier in centralized systems and our decentalization is why it's hard for us; if we make it, we make be the first ever! - + **Woke Warning:** gender specific, non-android/furry friendly grammar is used throughout. @@ -303,7 +303,7 @@ the possibilities are endless. The changes to the core are not large: 1. Change the status message callback to look for public signing keys -2. Change the status message callback to look for blobs as a first +2. Change the status message callback to look for blobs as a first implementation, and then later extend the avatar file transfer mechanism to transfer blobs 3. Use the public signing keys to verify the blobs. This a NaCl call. diff --git a/QToxGreen.md b/QToxGreen.md index edfa665..05748f8 100644 --- a/QToxGreen.md +++ b/QToxGreen.md @@ -5,17 +5,17 @@ Up: [[Home]] ## Zoominfo LinkedIn -Works full time as: +Works full time as: > C Software Engineer & Open Source Project Application -> Developer & Firmware Maintainer & Developer at Avigilon +> Developer & Firmware Maintainer & Developer at Avigilon -* https://www.zoominfo.com/p/Anthony-Bilinski/628037601 +* https://www.zoominfo.com/p/Anthony-Bilinski/628037601 * https://ca.linkedin.com/in/anthony-bilinski-b4178611a (archive: https://archive.ph/X6Tsy ) * https://www.zoominfo.com/p/Anthony-Bilinski/3246706849 So he's working on Open Source projects as his day job at Avigilon May 2016 - Sep 2021 - 5 years 5 months. Maybe qTox was his day job until Sept 2021? -Avigilon is a video surveillance hardware and software company founded in 2004, went public on the VSE and was bought out by Motorolla. His zoominfo listing gives +Avigilon is a video surveillance hardware and software company founded in 2004, went public on the VSE and was bought out by Motorolla. His zoominfo listing gives ```a***@curtiswright.com``` as his email. Curtiswright is a well know USGov contractor. He did an Internship at Curtis in 2014, so the @curtiswright email may not be current - an old zoominfo address. His boss and colleague on the zoominfo.com list both check out. His boss was a [well-known Security Industry professional](https://www.sdmmag.com/articles/100828-security-industry-mourns-the-loss-of-matthew-krebs) not based in Canada. @@ -23,14 +23,14 @@ His boss and colleague on the zoominfo.com list both check out. His boss was a [ ## Website His web site no longer responds https://www.abilinski.com/ -It was just a one page pointing to a ToxId +It was just a one page pointing to a ToxId * https://web.archive.org/web/20180825193239/https://www.abilinski.com/ His BS nodes no longer respond: * tox.abilinski.com * tox2.abilinski.com -There is no github activity since July: +There is no github activity since July: * https://github.com/qtox/qtox * https://github.com/anthonybilinski @@ -44,5 +44,5 @@ in February, but no idea who is the sponsor. It looks like `sphaerophoria` spons But the licence for file for [toxext](https://github.com/toxext/toxext/), a sphaerophoria project initialy came from -[anthonybilinski/add-licence](https://github.com/toxext/toxext/commits?author=sphaerophoria) so they may be the same person. - +[anthonybilinski/add-licence](https://github.com/toxext/toxext/commits?author=sphaerophoria) so they may be the same person. + diff --git a/SecurityVulnerabilities.md b/SecurityVulnerabilities.md index 8d130a9..f8bb670 100644 --- a/SecurityVulnerabilities.md +++ b/SecurityVulnerabilities.md @@ -8,7 +8,7 @@ Previous: [[Home]] ##mCVEs: -* [CVE-2018-25022](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25022) The Onion module in toxcore before 0.2.2 +* [CVE-2018-25022](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25022) The Onion module in toxcore before 0.2.2 See also: [[ToxComparedWithOtherIm]] diff --git a/ToxComparedWithOtherIm.md b/ToxComparedWithOtherIm.md index 7deec10..7c568f0 100644 --- a/ToxComparedWithOtherIm.md +++ b/ToxComparedWithOtherIm.md @@ -9,7 +9,7 @@ Up: [[SecurityVulnerabilities]] Always uses Tor, rather than Tox, where Tor can be used at will. * https: certificate expired over a year ago, and latest version in 2016. -* last updated 2017. +* last updated 2017. Relaunched as diff --git a/ToxMultiDevice.md b/ToxMultiDevice.md index d597070..12482e4 100644 --- a/ToxMultiDevice.md +++ b/ToxMultiDevice.md @@ -61,7 +61,7 @@ device will then send a “commit” packet, and will then commit the data from temporary storage, into active use. Once receiving the “commit” packet, the secondary device will do the same. -Either Client can send an Error packet at either time, which will then +Either Client can send an Error packet at either time, which will then Message ordering Devices may sync out of order, but messages need to be consistently @@ -108,8 +108,8 @@ Security and safety is the primary concern, however this needs to be tempered wi ### Device IDs -Device IDs need to be unique and never changing. On each connect, each client should query each friend they connect to, to verify if they support multi-device AND are in a group. This can be done by asking for the deviceID at ```__device0```. If there is a device at that address; then enumerate for each other device. -Devices will be found by the string_to_id service using the protected `__device[0-9]+` group. (Toxcore must protect strings that start with two underscores such as “__[string]”, and not allow a client to use them in the string_to_id API.) +Device IDs need to be unique and never changing. On each connect, each client should query each friend they connect to, to verify if they support multi-device AND are in a group. This can be done by asking for the deviceID at ```__device0```. If there is a device at that address; then enumerate for each other device. +Devices will be found by the string_to_id service using the protected `__device[0-9]+` group. (Toxcore must protect strings that start with two underscores such as “__[string]”, and not allow a client to use them in the string_to_id API.) Starting with ```__device0```, the client will attempt to resolve the @@ -125,7 +125,7 @@ be in an unsecure state, and shouldn’t send any messages to any of the devices. -The ```__device#``` list for every client must match exactly to what every other device reports. And each ```__device#``` once used must always resolve to that ID. +The ```__device#``` list for every client must match exactly to what every other device reports. And each ```__device#``` once used must always resolve to that ID. To enhance security once a ```__device#``` (number) is taken by a @@ -153,7 +153,7 @@ friend/contact list, and the selected amount of history text history to the new device. -A max limit of devices will need to be chosen later to limit worst case usage of enumerating devices. (Additional protocol requirements will be detailed later, i.a. security limitations, verifiable, master device, slave device, deauthed devices.) +A max limit of devices will need to be chosen later to limit worst case usage of enumerating devices. (Additional protocol requirements will be detailed later, i.a. security limitations, verifiable, master device, slave device, deauthed devices.) ## Message sending @@ -191,7 +191,7 @@ It is considered the job of the receiving client to keep all the other devices i How will messages be hashed to generate the seed for the message ID? -Effective and secure history syncing across devices. +Effective and secure history syncing across devices. How to add a user to your contact list @@ -222,7 +222,7 @@ Conversations that need to be added to the spec: will Alice see the file request on both clients? the file request will go to all online devices ok, i'm not finished - then the file will get canceled / "marked as accpeted on a different device" + then the file will get canceled / "marked as accpeted on a different device" so, Alice accepts and completes the file transfer on her phone ``` (h)[^8] (i)[^9] (j)[^10] @@ -241,7 +241,7 @@ Conversations that need to be added to the spec: yes, but it will ignore the 2nd how it knows which to ignore? (I'm saying all of this from what my plans are, I haven't even started on filetransfers yet) - psudo code -> + psudo code -> Alice might have accepted the file transfer on the phone first, but because of network latency, Bob received the acceptance from pc first and only then from the phone OH bob will in that case cancel the phone then @@ -268,14 +268,14 @@ Conversations that need to be added to the spec: * [a][^1] Does this design document define a way in which friends (and perhaps groups) are to be synced? And how would friend/group syncing work across multi-devices that don't have a common time base? -* [b][^2] I haven't fully decided on the final spec for this question. +* [b][^2] I haven't fully decided on the final spec for this question. Currently my plan is to retain information about changes as a numerical delta, and use the largest delta. But as I haven't started on this section, really I have no idea. * [c][^3] What about in the case of an A/V call? Does that get broadcast to call connected clients or only the last 3? A tox client running on a mobile device that had not sent a user-generated message missing a call would be bad. -* [d][^4] I'm likely to drop that idea in total. +* [d][^4] I'm likely to drop that idea in total. Currently toxcore sends everything to all devices. * [e][^5] With other services such as Discord, when a call comes in depending on what is on, I could have two PCs, a laptop and cellphone all ring, but whatever device I answer on obviously gets the call. diff --git a/ToxNetworkResilience.md b/ToxNetworkResilience.md new file mode 100644 index 0000000..f3eda65 --- /dev/null +++ b/ToxNetworkResilience.md @@ -0,0 +1,41 @@ +Up: [[Home]] + +Tox relies on "bootstrap" nodes to be able to find your Friends. That +list of nodes is quite small, < 100, and you can find it in the file +often called DHTnodes.json. If a country like Iran can block those +nodes, they can block Tox. Whether Tox is encrypted makes no difference +in their ability to block. + +Tox works well over [Tor](https://torproject.org/), which should help. +If they can't block Tor, then they can't block Tox over Tor. And Tor +is evolving stratagies to help defeat blocking, like +[snowflake](https://torproject.org/). As Tor evolves its resillience +strategies, Tox over Tor evolves with it. It is *much* harder to block +Tox over Tor than to block services like WhatsApp which relay on +centralized servers, unless the service runs a OnionV3 Tor service +that makes if accesible directly over Tor. + +Everyone who wants to help the network be resilient to blocking should +run their clients like [toxic](https://github.com/JFreegman/toxic/) +with the ```-T, --tcp-relay``` if they are not using Tor. Choose a +random port number ```> 10000 < 65000``` for the port. +If you are not running over Tor and are on a stable connection, try it. + +Every BSnode operator who wants to help the network be resilient in +places like Iran should run a Tor server that provides the node as an +onionV3 service; see [[ToxAndTorInChina]]. + +If you run a bootstrap node, you can run a Tor Ononv3 gateway to the +node by simply adding the following lines to your ```torrc``` +configuration: +``` +# Tox hidden service configuration. +HiddenServiceDir /var/lib/tor/tox-hsv3/ +HiddenServicePort 3389 127.0.0.1:3389 +HiddenServicePort 3389 127.0.0.1:33446 +``` +assuming your Tor lib directory os ```/var/lib/tor```. In that subdirectory +you will find a file named ```hostname``` which is the ```.onion``` name +of your node, the Tor equivalent of your ToxId. + +