C-toxcore: Documentez les questions et les réponses liées aux réseaux crypto et p2p

Tu te trompes. Des nœuds d'amorçage DHT existent pour faciliter l'adhésion au DHT. Si vous souhaitez plus d'explications, vous pouvez consulter cet article : https://en.wikipedia.org/wiki/Distributed_hash_table. Alternativement, vous pouvez nous rejoindre sur IRC, sur le canal #tox sur Freenode, et nous essaierons de vous expliquer les choses du mieux que nous pourrons.

Votre trafic peut passer par des nœuds d'amorçage agissant comme des relais TCP tandis que tox utilise TCP pour la connexion ami. C'est similaire à TURN . Votre trafic est toujours crypté de bout en bout, de sorte que la confidentialité et l'authenticité de vos messages ne sont jamais compromises. Ce relais TCP est probablement ce que vous avez vu dans votre analyse du trafic. Il est décrit en détail dans la spécification du protocole tox .

C'est un trafic vocal. Il est crypté et les tiers ne peuvent plus le décrypter, mais cela ne signifie pas que ce sera impossible à l'avenir.

J'ai une adresse IPv4/IPv6 directe. Pourquoi devrais-je envoyer mes données aux nœuds ?
Vous dites - "Des nœuds d'amorçage DHT existent pour faciliter l'adhésion au DHT.", Mais ce n'est pas vrai. Dans la capture d'écran ci-jointe, le trafic passe par un nœud, pas directement vers moi.

« Tox est un logiciel facile à utiliser qui vous connecte avec vos amis et votre famille sans que personne d'autre ne vous écoute. » - c'est un mensonge ? Trafic crypté, ok. Mais il utilise des nœuds pour la livraison ? Je ne sais pas qui a maintenu ces nœuds. Que faire si un ou plusieurs nœuds sont faux ?

Je comprends à quel point ce point peut sembler incorrect, j'ai donc déposé un problème de documentation pour améliorer notre présentation à ce sujet. Merci d'avoir expliqué vos pensées.

Pour expliquer rapidement votre préoccupation spécifique, je vais la paraphraser. Merci de me dire si j'ai mal compris :

Q : _Je suis préoccupé par le fait que les paquets de données provenant de mon ordinateur ne sont pas livrés directement à l'ordinateur de mon ami, mais sont parfois (ou tout le temps, selon les conditions du réseau) relayés via des ordinateurs tiers._

R : Considérons tout d'abord un paquet allant directement de votre ordinateur à l'ordinateur de votre ami, en supposant que vous êtes sur un réseau Wi-Fi local :

• Votre ordinateur crée un paquet Tox chiffré (voir détail du chiffrement ), qu'il enveloppe dans un paquet UDP contenant les ports source/destination (aléatoire/33445), puis dans un paquet IP contenant les adresses IP source/destination (vous et votre ami) , puis une trame sans fil contenant les adresses MAC source/destination (vous et le(s) point(s) d'accès).
• Cette trame sans fil est envoyée sur un canal crypté AES (en supposant que WPA2).
• Le point d'accès sans fil ainsi que tous les autres utilisateurs du réseau le reçoivent. Les autres utilisateurs ignorent généralement le paquet, mais ne sont pas obligés de le faire. Lire des paquets qui ne vous sont pas destinés s'appelle renifler. C'est le premier point auquel d'autres peuvent lire le paquet.
• Le point d'accès sans fil est connecté à un routeur WAN (Internet) qui établit une connexion avec les routeurs de votre fournisseur d'accès Internet via certains moyens (couplage acoustique, RNIS, ADSL, câble, satellite, fibre, ...). Cette connexion peut être cryptée (certains satellites) mais ne l'est généralement pas. À ce stade, le routeur WAN auquel vous avez envoyé votre paquet créera une trame Ethernet contenant sa propre adresse MAC et l'adresse MAC du prochain routeur auquel il se connecte, qui est votre routeur FAI. En transit, les adresses IP et MAC ne sont probablement pas chiffrées et peuvent être lues par quiconque renifle la fibre optique entre vous et le FAI. C'est le deuxième point auquel d'autres peuvent lire le paquet.
• Une fois le paquet arrivé chez le FAI, il passera par divers systèmes internes dans leurs centres de données, éventuellement cryptés ou non cryptés à différents moments. Le routeur ISP décidera alors du prochain routeur auquel il doit envoyer le paquet, déterminé par l'adresse IP. Pour ce faire, il déballera la trame Ethernet qu'il a reçue et l'enveloppera dans une nouvelle et l'enverra au routeur suivant. À tout moment pendant le traitement chez le FAI, les employés du centre de données ou de l'administration système de ce FAI peuvent accéder à votre paquet. Troisième point d'accès.
• Maintenant, votre paquet passera d'un routeur à l'autre (essayez traceroute $your_friend_ip pour voir où il va), chacun ayant un accès libre à la trame Ethernet, au paquet IP et au paquet UDP ainsi qu'à son contenu. De nombreux points d'accès, appelons-le le 4ème.
• Ensuite, votre ami peut être dans une situation similaire, dans un wifi local à un endroit différent. Là encore, leur routeur et les membres du réseau sans fil peuvent lire le paquet. Cinquième point d'accès.
• Seulement maintenant, enfin, votre paquet arrive sur l'ordinateur de votre ami. Il reçoit une trame sans fil, la déballe pour trouver un paquet IP, la déballe pour trouver un paquet UDP, la déballe pour trouver un paquet Tox, qui est ensuite traité par l'implémentation du protocole Tox. Ce traitement implique de déchiffrer et de décoder le paquet et d'agir dessus, ce qui entraîne généralement l'affichage du message par le client de votre ami, la lecture audio ou vidéo ou l'exécution d'une autre activité au niveau de l'application.

Comme vous le voyez, il existe de nombreux points lors de la transmission "directe" de vous à votre ami où le paquet peut être inspecté par des personnes arbitraires. Le cryptage de bout en bout signifie qu'à aucun moment entre vous et votre ami, quelqu'un ne peut lire le contenu réel que vous vouliez transmettre. Ils ne peuvent toujours voir que les données cryptées.

Maintenant, ajouter un relais TCP au milieu allongera simplement la route (cela pourrait théoriquement la raccourcir, mais ce n'est pas probable). Toute personne exécutant le relais peut lire le paquet, comme n'importe qui d'autre entre vous et votre ami. Le protocole crypto Tox garantit que votre communication est sécurisée.

Maintenant, je vois aussi un deuxième souci:

Q : _Que se passe-t-il si l'un des nœuds relayant mes données est mauvais ?_
R : Tox sélectionne un certain nombre de relais TCP qu'il peut utiliser pour communiquer au cas où les connexions UDP directes ne seraient pas possibles (par exemple en raison du NAT ou du pare-feu). Les relais maléfiques peuvent faire très peu de choses pour faire le mal :

• Ils peuvent choisir de ne pas envoyer le paquet. Dans ce cas, Tox réessayera via un relais différent. Ce n'est que si tous les nœuds d'amorçage sont mauvais qu'une transmission échouera.
• Ils peuvent envoyer un paquet modifié. Grâce aux codes d'authentification des messages, toute altération des données est susceptible d'être détectée. Si l'expéditeur parvient à falsifier d'une manière qui n'est pas détectée par le logiciel, le paquet déchiffré sera un déchet et la couche application (le décodeur de protocole Tox) le rejettera. Cela a donc le même effet que de ne pas relayer du tout le paquet.

C'est fondamentalement ça. En aucun cas le relais maléfique ne pourra lire vos données. Il peut seulement choisir de ne pas relayer, et seulement si chaque nœud d'amorçage est mauvais, vous ne pouvez pas communiquer. Ce serait assez ennuyeux et nous en serions mécontents, mais les informations de personne ne sont compromises à aucun moment.

J'espère que cela clarifie certaines choses. Je n'ai pas relu cette réponse, mais je m'assurerai qu'elle est correctement représentée sur le site Web pour référence future. Faites-moi savoir si vous avez d'autres préoccupations. Merci encore d'avoir soulevé cette question.

Je viens de relire votre message et j'ai découvert que j'avais raté une autre préoccupation :

Q : Bien que les données soient désormais chiffrées, qu'est-ce qui garantit qu'elles ne seront pas déchiffrées à l'avenir ?
R : Le protocole Tox met en œuvre une parfaite confidentialité de transmission grâce à l'utilisation de clés éphémères. Cela signifie que si l'une de ces clés est compromise, quelques messages peuvent être déchiffrés, mais pas l'intégralité de votre historique de communication. La partie "quelques messages" de cette phrase sera réduite à "un message" à l'avenir. Si votre clé secrète à long terme est compromise, aucune communication passée ne peut être déchiffrée.

Si les primitives cryptographiques que nous utilisons sont cassées, nous perdons. Cela dépend de la manière dont ils sont cassés, ce sont les pires scénarios possibles :

• Le chiffrement ( salsa20 ) peut être facilement inversé sans clé. Dans ce cas, toutes les communications passées sont compromises.
• La primitive d'échange de clé ( courbe25519 ) est cassée de manière à ce que la clé secrète puisse facilement être récupérée avec une clé publique. Dans ce cas, toutes les communications passées sont également compromises.

Il est très peu probable que ces scénarios deviennent réalité dans un avenir proche, voire pour toujours. D'après les connaissances actuelles de la communauté de la cryptographie, seul l'informatique quantique pourrait permettre au deuxième scénario de se produire. Le premier scénario est considéré comme impossible.

Cela dit, j'ai aussi remarqué que vous avez dit que vous aviez une adresse IPv4 directe. Qu'est-ce que ça veut dire? Si vous avez une adresse IPv4 publique attribuée à votre ordinateur et que le port 33445 est ouvert, Tox devrait établir des connexions directes très rapidement. Si ce n'est pas le cas, c'est un bogue et nous devrions travailler ensemble pour savoir pourquoi il choisit d'utiliser TCP à la place.

Merci beaucoup pour cette explication. Maintenant je comprends un peu plus.
Je ne suis pas sûr de l'adresse IPv4 directe... J'utilise WireGuard VPN. WireGuard installé sur un serveur virtuel, qui a une adresse IPv4 et IPv6 directe. Tout le trafic est enveloppé dans un espace de noms.
Informations sur le réseau portable : https://gist.github.com/DebugReport/1268e15c3bd1c99b56929d645d99392b
Si je me suis trompé, je suis désolé.
IPv4 n'est peut-être pas direct, mais qu'en est-il d'IPv6 ? Je peux utiliser des connexions directes si un autre client a également IPv6 ?

Oui, si les deux parties ont IPv6 et que la configuration du pare-feu ne bloque pas le port 33445 (ou un autre port proche, quelque chose entre 33445 et 33545), cela devrait fonctionner. Votre ami est-il dans le même VPN ?

Non.
Hum... Question. Nous devons toujours utiliser des nœuds ? Ou seulement si l'un de nous n'a pas d'IP direct (IPv4 uniquement ?) ?
Pour IPv6 (moi) <-> IPv6 (ami), les nœuds sont-ils nécessaires ? Si oui - pourquoi ?

(Garder ce problème ouvert jusqu'à ce que toutes ces questions soient répondues dans la documentation)

Si l'un de vous a une adresse IP publique, l'autre peut démarrer en utilisant l'adresse IP et le port de l'autre. Cela nécessite un support client, je ne pense pas qu'un client ait actuellement :

• Obtenez la clé publique DHT du client avec une adresse IP publique et un port ouvert ( tox_self_get_dht_id ) et son port ( tox_self_get_udp_port ).
• Envoyez cette clé à l'autre d'une manière ou d'une autre (dictez par téléphone ou par message sur Skype ou autre).
• L'autre doit maintenant démarrer en utilisant le tuple (key, ip, port) .

Après cela, vous disposez d'un réseau Tox personnel de 2 personnes. Donc, en théorie, vous n'avez pas besoin d'autres nœuds. Ils facilitent les choses, cependant.

Si l'un de vous a une adresse IP publique et un port ouvert, la connexion aux nœuds d'amorçage devrait également vous permettre d'établir une connexion directe. Les nœuds d'amorçage DHT ont peu à voir avec le fait que vous puissiez vous connecter ou non. Une connexion directe devrait être possible même si un seul d'entre vous a une adresse IP publique et un port ouvert. L'autre s'y connecterait, ce qui créerait une route dans le routeur local et donnerait au client un port public aléatoire temporaire.

Juste une remarque : j'ai remarqué le même comportement avec C-Toxcore. L'une des parties est sur un VPS avec une adresse IP publique et sans pare-feu, l'autre est derrière NAT mais a le port Tox transféré - elles doivent donc être mutuellement joignables. Le trafic était toujours acheminé via TCP.

Je ne vois pas cela comme un problème de sécurité, mais c'est certainement un problème d'évolutivité si un réseau P2P relaie tout son trafic via des relais.