C-toxcore: Dokumentieren Sie Fragen und Antworten zu Krypto- und P2P-Netzwerken

Du liegst falsch. Es gibt DHT-Bootstrap-Knoten, um den Beitritt zur DHT zu erleichtern. Wenn Sie weitere Erklärungen wünschen, können Sie sich diesen Artikel ansehen: https://en.wikipedia.org/wiki/Distributed_hash_table. Alternativ können Sie sich uns im IRC im #tox-Kanal auf Freenode anschließen, und wir werden versuchen, die Dinge so gut wie möglich zu erklären.

Ihr Datenverkehr kann Bootstrap-Knoten durchlaufen, die als TCP-Relays fungieren, während tox TCP für die Friend-Verbindung verwendet. Es ist ähnlich wie TURN . Ihr Datenverkehr ist immer noch Ende-zu-Ende-verschlüsselt, sodass die Vertraulichkeit und Authentizität Ihrer Nachrichten niemals gefährdet sind. Dieses TCP-Relaying ist wahrscheinlich das, was Sie in Ihrer Verkehrsanalyse gesehen haben. Es ist detailliert in der Tox-Protokollspezifikation beschrieben.

Es ist ein Sprachverkehr. Es ist verschlüsselt und jetzt können Dritte dies nicht entschlüsseln, aber das bedeutet nicht, dass es in Zukunft unmöglich ist.

Ich habe eine direkte IPv4/IPv6-Adresse. Warum sollte ich meine Daten an Knoten senden?
Sie sagen: „DHT-Bootstrap-Knoten existieren, um den Beitritt zur DHT zu erleichtern“, aber das stimmt nicht. Im beigefügten Screenshot wird der Datenverkehr durch einen Knoten geleitet, nicht direkt zu mir.

'Tox ist eine einfach zu bedienende Software, die Sie mit Freunden und Familie verbindet, ohne dass jemand anderes zuhört. ' - ist es eine Lüge? Datenverkehr verschlüsselt, ok. Aber es verwendet Knoten für die Lieferung? Ich weiß nicht, wer diese Knoten gepflegt hat. Was ist, wenn ein oder mehrere Knoten falsch sind?

Ich verstehe, dass sich dieser Punkt falsch anfühlen kann, deshalb habe ich ein Dokumentationsproblem gemeldet, um unsere Darstellung davon zu verbessern. Vielen Dank für die Erläuterung Ihrer Gedanken.

Um Ihr spezielles Anliegen schnell zu erklären, werde ich es paraphrasieren. Bitte lassen Sie mich wissen, wenn ich es falsch verstanden habe:

F: _Ich bin besorgt darüber, dass Datenpakete, die von meinem Computer kommen, nicht direkt an den Computer meines Freundes geliefert werden, sondern manchmal (oder ständig, je nach Netzwerkbedingungen) über Computer von Drittanbietern weitergeleitet werden._

A: Stellen Sie sich zunächst ein Paket vor, das direkt von Ihrem Computer zum Computer Ihres Freundes geht, vorausgesetzt, Sie befinden sich in einem lokalen WLAN:

• Ihr Computer erstellt ein verschlüsseltes Tox-Paket (siehe Verschlüsselungsdetails ), das er in ein UDP-Paket mit den Quell-/Zielports (random/33445) und dann in ein IP-Paket mit den Quell-/Ziel-IP-Adressen (Sie und Ihr Freund) verpackt. , dann ein Wireless-Frame mit den Quell-/Ziel-MAC-Adressen (Sie und Zugangspunkt(e)).
• Dieser Wireless-Frame wird über einen AES-verschlüsselten Kanal gesendet (WPA2 vorausgesetzt).
• Der Wireless Access Point sowie alle anderen Benutzer des Netzwerks erhalten es. Andere Benutzer ignorieren das Paket normalerweise, müssen es aber nicht. Das Lesen von Paketen, die nicht für Sie bestimmt sind, wird als Sniffing bezeichnet. Dies ist der erste Punkt, an dem andere das Paket lesen können.
• Der Wireless Access Point ist mit einem WAN (Internet)-Router verbunden, der auf irgendeine Weise eine Verbindung zu den Routern Ihres Internetdienstanbieters herstellt (akustische Kopplung, ISDN, ADSL, Kabel, Satellit, Glasfaser, ...). Diese Verbindung kann verschlüsselt sein (einige Satelliten), ist es aber normalerweise nicht. An diesem Punkt erstellt der WAN-Router, an den Sie Ihr Paket gesendet haben, einen Ethernet-Frame, der seine eigene MAC-Adresse und die MAC-Adresse des nächsten Routers enthält, mit dem er eine Verbindung herstellt, bei dem es sich um Ihren ISP-Router handelt. Während der Übertragung sind die IP- und MAC-Adressen wahrscheinlich unverschlüsselt und können von jedem gelesen werden, der die Glasfaser zwischen Ihnen und dem ISP ausspioniert. Dies ist der zweite Punkt, an dem andere das Paket lesen können.
• Sobald das Paket beim ISP ankommt, durchläuft es verschiedene interne Systeme in seinen Rechenzentren, möglicherweise zu verschiedenen Zeitpunkten verschlüsselt oder unverschlüsselt. Der ISP-Router entscheidet dann anhand der IP-Adresse, an welchen nächsten Router er das Paket senden soll. Dazu entpackt er den empfangenen Ethernet-Frame, verpackt ihn in einen neuen und sendet ihn an den nächsten Router. Zu jedem Zeitpunkt während der Verarbeitung beim ISP, im Rechenzentrum oder in der Systemadministration dieses ISP können Sie auf Ihr Paket zugreifen. Dritter Zugangspunkt.
• Jetzt springt Ihr Paket von Router zu Router (probieren Sie traceroute $your_friend_ip , um zu sehen, wohin es geht), von denen jeder freien Zugriff auf den Ethernet-Frame, das IP-Paket und das UDP-Paket sowie seinen Inhalt hat. Viele Zugangspunkte, nennen wir es den 4.
• Dann befindet sich Ihr Freund möglicherweise in einer ähnlichen Situation, in einem lokalen WLAN an einem anderen Ort. Wieder können ihr Router und Mitglieder des drahtlosen Netzwerks das Paket lesen. Fünfter Zugangspunkt.
• Erst jetzt kommt Ihr Paket endlich beim Computer Ihres Freundes an. Es empfängt einen Wireless-Frame, entpackt ihn, um ein IP-Paket zu finden, entpackt ihn, um ein UDP-Paket zu finden, entpackt ihn, um ein Tox-Paket zu finden, das dann von der Tox-Protokollimplementierung verarbeitet wird. Diese Verarbeitung umfasst das Entschlüsseln und Decodieren des Pakets und das Einwirken darauf, was normalerweise dazu führt, dass der Client Ihres Freundes die Nachricht anzeigt, Audio oder Video abspielt oder eine andere Aktivität auf Anwendungsebene durchführt.

Wie Sie sehen, gibt es während der "direkten" Übertragung von Ihnen zu Ihrem Freund viele Punkte, an denen das Paket von beliebigen Personen inspiziert werden kann. Ende-zu-Ende-Verschlüsselung bedeutet, dass zu keinem Zeitpunkt zwischen Ihnen und Ihrem Freund jemand die eigentlichen Inhalte lesen kann, die Sie übermitteln wollten. Sie können immer nur die verschlüsselten Daten sehen.

Wenn Sie jetzt ein TCP-Relay in der Mitte hinzufügen, wird die Route einfach verlängert (es könnte sie theoretisch verkürzen, aber das ist nicht wahrscheinlich). Jeder, der das Relay betreibt, kann das Paket lesen, genau wie jeder andere zwischen Ihnen und Ihrem Freund. Das Tox-Kryptoprotokoll sorgt dafür, dass Ihre Kommunikation sicher ist.

Jetzt sehe ich auch eine zweite Sorge:

F: _Was passiert, wenn einer der Knoten, der meine Daten weiterleitet, böse ist?_
A: Tox wählt eine Reihe von TCP-Relays aus, mit denen es kommunizieren kann, falls direkte UDP-Verbindungen nicht möglich sind (z. B. aufgrund von NAT oder Firewall). Böse Relais können nur sehr wenige Dinge tun, um Böses zu tun:

• Sie können sich dafür entscheiden, das Paket nicht zu senden. In diesem Fall versucht Tox es erneut über ein anderes Relais. Nur wenn alle Bootstrap-Knoten böse sind, schlägt eine Übertragung fehl.
• Sie können ein modifiziertes Paket senden. Dank Nachrichtenauthentifizierungscodes wird jede Manipulation der Daten wahrscheinlich erkannt. Wenn es dem Absender gelingt, auf eine Weise zu manipulieren, die von der Software nicht erkannt wird, ist das entschlüsselte Paket Müll, und die Anwendungsschicht (der Tox-Protokoll-Decoder) wird es verwerfen. Dies hat daher den gleichen Effekt wie das Paket überhaupt nicht weiterzuleiten.

Das ist es im Grunde. In keinem Fall kann das böse Relais Ihre Daten lesen. Es kann nur wählen, nicht weiterzuleiten, und nur wenn jeder Bootstrap-Knoten böse ist, können Sie nicht kommunizieren. Das wäre ziemlich ärgerlich und wir wären unglücklich darüber, aber die Informationen von niemandem werden zu irgendeinem Zeitpunkt kompromittiert.

Ich hoffe, das verdeutlicht einige Dinge. Ich habe diese Antwort nicht Korrektur gelesen, aber ich werde dafür sorgen, dass sie auf der Website für zukünftige Referenzzwecke richtig dargestellt wird. Lassen Sie mich wissen, wenn Sie andere Bedenken haben. Nochmals vielen Dank, dass Sie dies angesprochen haben.

Ich habe gerade Ihre Nachricht noch einmal gelesen und festgestellt, dass ich ein weiteres Anliegen übersehen habe:

F: Obwohl Daten jetzt verschlüsselt sind, was stellt sicher, dass sie in Zukunft nicht mehr entschlüsselt werden?
A: Das Tox-Protokoll implementiert Perfect Forward Secrecy durch die Verwendung kurzlebiger Schlüssel. Das bedeutet, dass, wenn einer dieser Schlüssel kompromittiert wird, einige Nachrichten entschlüsselt werden können, aber nicht Ihr gesamter Kommunikationsverlauf. Der „ein paar Nachrichten“-Teil dieses Satzes wird in Zukunft auf „eine Nachricht“ reduziert. Wenn Ihr langfristiger geheimer Schlüssel kompromittiert ist, kann keine frühere Kommunikation entschlüsselt werden.

Wenn die von uns verwendeten kryptografischen Primitive kaputt sind, verlieren wir. Es kommt darauf an, auf welche Weise sie kaputt sind, das sind mögliche Worst-Case-Szenarien:

• Die Chiffre ( salsa20 ) kann ohne Schlüssel einfach rückgängig gemacht werden. In diesem Fall wird die gesamte frühere Kommunikation kompromittiert.
• Das Schlüsselaustausch-Primitiv ( curve25519 ) ist so gebrochen, dass der geheime Schlüssel bei einem öffentlichen Schlüssel leicht wiederhergestellt werden kann. In diesem Fall wird auch die gesamte frühere Kommunikation kompromittiert.

Es ist sehr unwahrscheinlich, dass diese Szenarien in naher Zukunft oder möglicherweise für immer Realität werden. Nach derzeitigem Verständnis in der Kryptographie-Community könnte nur Quantencomputer das zweite Szenario verwirklichen. Das erste Szenario gilt als unmöglich.

Nach alledem ist mir auch aufgefallen, dass Sie sagten, Sie hätten eine direkte IPv4-Adresse. Was bedeutet das? Wenn Sie Ihrem Computer eine öffentliche IPv4-Adresse zugewiesen haben und Port 33445 offen ist, sollte Tox sehr schnell direkte Verbindungen herstellen. Wenn dies nicht der Fall ist, handelt es sich um einen Fehler, und wir sollten zusammenarbeiten, um herauszufinden, warum TCP stattdessen verwendet wird.

Vielen Dank für diese Erklärung. Jetzt verstehe ich etwas mehr.
Ich bin mir bei der direkten IPv4-Adresse nicht sicher ... Ich verwende WireGuard VPN. WireGuard ist auf einem virtuellen Server installiert, der eine direkte IPv4- und IPv6-Adresse hat. Der gesamte Datenverkehr wird in den Namensraum eingeschlossen.
Informationen zum Laptop-Netzwerk: https://gist.github.com/DebugReport/1268e15c3bd1c99b56929d645d99392b
Wenn ich mich geirrt habe, tut es mir leid.
Vielleicht ist IPv4 nicht direkt, aber was ist mit IPv6? Ich kann direkte Verbindungen verwenden, wenn ein anderer Client auch IPv6 hat?

Ja, wenn beide Parteien IPv6 haben und die Firewall-Konfiguration Port 33445 (oder einen anderen Port in der Nähe davon, etwas zwischen 33445 und 33545) nicht blockiert, sollte es funktionieren. Befindet sich Ihr Freund im selben VPN?

Nein.
Hmm ... Frage. Wir müssen immer Knoten verwenden? Oder nur, wenn einer von uns keine direkte IP hat (nur IPv4?)?
Sind für IPv6 (me) <-> IPv6 (friend) Nodes notwendig? Wenn ja - warum?

(Halten Sie dieses Problem offen, bis alle diese Fragen in der Dokumentation beantwortet sind.)

Wenn einer von Ihnen eine öffentliche IP hat, kann der andere mit der IP und dem Port des anderen booten. Dies erfordert Client-Support, von dem ich glaube, dass derzeit kein Client Folgendes hat:

• Holen Sie sich den öffentlichen DHT-Schlüssel vom Client mit öffentlicher IP und offenem Port ( tox_self_get_dht_id ) und seinem Port ( tox_self_get_udp_port ).
• Schicken Sie diesen Schlüssel irgendwie an den anderen (per Telefon diktieren oder eine Nachricht über Skype oder so).
• Der andere muss nun mit dem Tupel (key, ip, port) booten.

Danach haben Sie ein persönliches 2-Personen-Tox-Netzwerk. Theoretisch benötigen Sie also keine weiteren Knoten. Sie machen die Sache aber einfacher.

Wenn einer von Ihnen eine öffentliche IP und einen offenen Port hat, sollten Sie durch die Verbindung mit Bootstrap-Knoten auch eine direkte Verbindung herstellen können. DHT-Bootstrap-Knoten haben wenig damit zu tun, ob Sie eine Verbindung herstellen können oder nicht. Eine direkte Verbindung sollte möglich sein, auch wenn nur einer von Ihnen eine öffentliche IP und einen offenen Port hat. Der andere würde sich damit verbinden, was eine Route im lokalen Router erstellen und dem Client einen temporären zufälligen öffentlichen Port geben würde.

Nur eine Anmerkung: Ich habe das gleiche Verhalten bei C-Toxcore festgestellt. Eine der Parteien befindet sich auf einem VPS mit einer öffentlichen IP-Adresse und ohne Firewall, die andere befindet sich hinter NAT, hat aber den Tox-Port weitergeleitet - sie sollten also gegenseitig erreichbar sein. Der Datenverkehr wurde weiterhin über TCP geleitet.

Ich sehe dies nicht als Sicherheitsproblem, aber es ist sicherlich ein Problem der Skalierbarkeit, wenn ein P2P-Netzwerk seinen gesamten Datenverkehr über Relais weiterleitet.