Mit genug Aufwand geht alles, die Frage ist ob es das wert ist, und ob du es soweit automatisieren kannst das es irgend ein DAU in einer Behörde bedienen kann.
Bei den ganzen theoretischen ifs und buts von denen die Authoren ausgehen halte ich das für eher unwahrscheinlich.
Sowas wie 100%ige Anonymität gibt es eh nicht, du kannst es denn anderen nur so schwer wie möglich machen dass sie das Interesse verlieren.
Wer irgend einen hoch illegalen Scheiß auf einer EEP Seite in seinen eigenen 4 Wänden hostet fragt so oder so nach Ärger.
Aber ich bin mir Sicher Tarnkappe User sind alle Musterbürger die niemals nie nicht irgendwas verbotenes machen würden
Die I2P Entwickler benennen ja ganz klar, dass so lange IP-Adressen untereinander kommunizieren (müssen), dessen Identität mit genügend staatlichen Aufwand herausgefunden werden können.
Schwieriger wird es dann schon, den Inhalt, der im I2P-Netzwerk verschickt wird, zu ermitteln bzw. dessen einer IP-Adresse eindeutlig nachzuweisen.
I2P verschleiert also mehr den Inhalt, der im I2P Netzwerk versendet wird. Ein gewisser Nebeneffekt ist halt, dass man auch seine IP-Adresse in gewissen Ländern nicht ersichtlich machen kann, diese IP-Adresse nimmt dann nur über das Ausland Kontakt zum I2P-Netzwerk auf. Diese Funktion ist sicherlich wichtig in Ländern, es denen Anonymisierungsdienste blockiert werden, u.a. China.
Ja, I2P wird effektiv von Chinas Bevölkerung verwendet!
Schaut man sich die interne I2P-Netzwerkdatenbank an, so scheint I2P bisher die chinesische Firewall zu durchdringen, verglichen zu TOR.
Wenn man bedenkt, dass I2P seit 2005 das noch recht effiziente Zensurresistente Transportprotokoll SSU verwendet, so wird das neue SSU2 Protokoll, woran die I2P Entwickler 17Jahre gearbeitet haben, viele Schwachstellen das alten SSU beseitigen und für mehr Geschwindigkeit und geringere CPU Auslastung in I2p sorgen.
Dieses Protokoll wurde in der heute erschienenen
I2P 1.10.0 (API 0.9.56) veröffentlich
Das neue Protokoll verwendet und kombiniert die Merkmale der UDP-Protokolle WireGuard und QUIC, zusammen mit dem Zensur Widerstandsmerkmale des I2P TCP-Protokolls „NTCP2“.
SSU2 ist möglicherweise eines der sichersten Verkehrsprotokolle, die jemals entwickelt wurden.
Die Ziele sind:
Upgrade der asymmetrischen Kryptographie auf das viel schnellere X25519
Verwenden standardmäßig symmetrische authentifizierte Verschlüsselung ChaCha20/Poly1305
Verbesserung der Verschleierung und Blockierung von Widerstandsfunktionen der SSU
Verbessern Sie die Widerstandsfähigkeit gegen gefälschte Adressen durch Anpassung von Strategien von QUIC
Verbesserte CPU Effizienz
Verbesserte Bandbreiteneffizienz durch kleinere Handshakes und Anerkennungen
Verbesserung der Sicherheit der Vergleichstests und Relaisfunktionen der SSU
Verbesserten Umgang mit anderen IP- und Portwechseln, indem sich die "Verbindungsmigration"-Funktion von QUIC anpassen
Weg weg vom heuristischen Code für Pakethandling zu dokumentierter, algorithmischer Verarbeitung
Unterstützung eines schrittweisen Netzübergangs von SSU zu SSU2
Einfache Erweiterbarkeit mit dem Blockkonzept von NTCP2
Design
I2P verwendet mehrere Verschlüsselungsschichten, um den Verkehr vor Angreifern zu schützen. Die unterste Schicht ist die Transportprotokollschicht, die für Punkt-zu-Punkt-Verbindungen zwischen zwei Routern verwendet wird. Es gibt derzeit zwei Verkehrsprotokolle: NTCP2, ein modernes TCP-Protokoll, das 2018 eingeführt wurde, und das alte SSU, ein im Jahr 2005 entwickeltes UDP-Protokoll.
SSU2, wie frühere I2P-Transportprotokolle, ist kein Allzweckrohr für Daten. Seine Hauptaufgabe ist es, die [Low-Level-I2NP-Nachrichten von I2P sicher zu liefern von einem Router zum nächsten. Jede dieser Punkt-zu-Punkt-Verbindungen besteht aus einem Hop in einem I2P-Tunnel. Höhere I2P-Protokolle überfahren diese Punkt-zu-Punkt-Verbindungen um Knoblauchbotschaften Ende-zu-Ende zwischen den Zielen von I2P zu liefern.
Die Gestaltung eines UDP-Transports stellt einzigartige und komplexe Herausforderungen dar, die in den TCP-Protokollen nicht vorlagen. Ein UDP-Protokoll muss Sicherheitsprobleme behandeln, die durch Adressfofälscht verursacht werden, und muss eine eigene Staukontrolle einführen. Darüber hinaus müssen alle Nachrichten fragmentiert sein, um in die maximale Paketgröße (MTU) zu passen, des Netzwerkpfades, und wieder zusammengesetzt vom Empfänger.
Genauere Informationen und sämtliche Funktionen des neuen SSU2 Protokolls kann man hier nachlesen:
https://geti2p.net/en/blog/post/2022/10/11/SSU2-Transport
Einen vorläufigen Changlog zur I2P 1.10.0 (API 0.9.56) steht hier:
Target release: November 2022
SSU2 connection migration
Enable SSU2 by default
Custom reseed service entry for Android
UDP Hidden Service/Client support in Hidden Services Manager
Automatic reseed servers from .onion URLs
VPN-Mode Support in Android for browser configuration
Update Android build process to use modern AGP, end need of deprecated Maven plugin in Android build
Cross-Platform(Desktop) I2P browser auto-configuration support
Die Aktualisierung der I2P Router erfolgt heute in etwa 4Std.
Funktionsweise von UDP (User Datagram Protocol)
UDP hat die selbe Aufgabe wie TCP, nur das nahezu alle Kontrollfunktionen fehlen, dadurch schlanker und einfacher zu verarbeiten ist.
So besitzt UDP keinerlei Methoden die sicherstellen, dass ein Datenpaket beim Empfänger ankommt. Ebenso entfällt die Nummerierung der Datenpakete. UDP ist nicht in der Lage die Datenpakete in der richtigen Reihenfolge zusammenzusetzen. Statt dessen werden die UDP-Pakete direkt an die Anwendung weitergeleitet. Für eine sichere Datenübertragung ist deshalb die Anwendung zuständig.
In der Regel wird UDP für Anwendungen und Dienste verwendet, die mit Paketverlusten umgehen können oder sich selber um das Verbindungsmanagement kümmern. UDP eignet sich auch für Anwendungen, die nur einzelne, nicht zusammenhängende Datenpakete transportieren müssen.
Anwendungsunterstützung durch Ports (Application Support)
Die Gemeinsamkeit von UDP und TCP ist die Port-Struktur, die mehreren Anwendungen gleichzeitig mehrere Verbindungen über das Netzwerk ermöglicht.
In jedem UDP-Datenpaket ist eine Nummer hinterlegt, die einen Port definiert, hinter dem sich eine Anwendung oder ein Dienst befindet, die diesen Port abhören und die Daten entgegennehmen. Die Port-Nummern beginnen von 0 an zu zählen und sind bis zur Port-Nummer 1.023 fest einer Anwendung zugeordnet. Die Port-Nummern bis 49.151 sind für Anwendungen registriert. Alle Port-Nummern darüber, können frei verwendet werden. Zum Beispiel als Absender-Port-Nummer. Der Empfänger eines Datenpakets schickt die Datenpakete an diesen Port zurück.
Mit der Port-Struktur wird sichergestellt, dass die Datenpakete an die richtige Anwendung übergeben werden.
UDP-Pakete setzen sich aus dem Header-Bereich und dem Daten-Bereich zusammen. Im Header sind alle Informationen enthalten, die eine einigermaßen geordnete Datenübertragung zulässt und die ein UDP-Paket als ein solches erkennen lassen. Der UDP-Header ist in 32-Bit-Blöcke unterteilt. Er besteht aus zwei solcher Blöcke, die den Quell- und Ziel-Port, die Länge des gesamten UDP-Pakets und die Check-Summe enthalten. Der UDP-Header ist mit insgesamt 8 Byte sehr schlank und lässt sich mit wenig Rechenleistung verarbeiten.
UDP - Header:
Anwendungen von UDP
In der Regel wird UDP für Anwendungen und Dienste verwendet, die mit Paketverlusten umgehen können oder sich selber um das Verbindungsmanagement kümmern. Typisch sind DNS-Anfragen, VPN-Verbindungen, Audio- und Video-Streaming. Ebenfalls eignet sich UDP für Anwendungsprotokolle, deren Datenumfang in ein Datenpaket hineinpasst. Beispielsweise bei einer DNS-Anfrage. Hier lohnt es sich nicht erst eine Verbindung aufzubauen und diese später wieder abzubauen. Geht dieses eine Datenpaket verloren, dann stellt man einfach die DNS-Anfrage noch mal.
Auch Tunnelprotokolle, nicht nur bei VPN, verwenden in der Regel UDP statt TCP. Das ist deshalb so, weil der Payload der Anwendungsprotokolle bereits in TCP-Paketen eingepackt ist und es keinen Sinn macht diese noch einmal in TCP-Pakete zu packen. In so einem Fall wirken sich TCP-Optimierungen wie Slow Start und Congestion Window negativ aufeinander aus.
Außerdem könnte man bei Verwendung eines TCP-Tunnels Anwendungen keine echtzeitorientierten Protokolle nutzen. Wie zum Beispiel Audio- und Video-Streaming. Hier ist man auf eine kontinuierliche Datenübertragung angewiesen, was mit TCP nicht möglich ist, weil die Daten hier nur fließen, wenn auch Bestätigungspakete zurückkommen.
Für Echtzeitanwendungen ist UDP viel besser geeignet, weil es hier kein begrenzendes Verbindungsmanagement gibt.
OSI - Schichtenmodell:
Das Transmission Control Protocol (TCP)
Für die Anwendungen ist TCP transparent. Die Anwendungen übergeben ihren Datenstrom an den TCP/IP-Stack und nehmen ihn von dort auch wieder entgegen. Mit der für die Übertragung nötige TCP-Paketstruktur sowie die Parameter der ausgehandelten Verbindung haben die Anwendungen nichts zu tun.
Aufgaben und Funktionen von TCP
-
Segmentierung (Data Segmenting): Dateien oder Datenstrom in Segmente teilen, Reihenfolge der Segmente wieder herstellen und zu Dateien oder einem Datenstrom zusammensetzen
-
Verbindungsmanagement (Connection Establishment and Termination): Verbindungsaufbau und Verbindungsabbau
-
Fehlerbehandlung (Error Detection): Bestätigung von Datenpaketen und Zeitüberwachung
-
Flusssteuerung (Flow Control): Dynamische Auslastung der Übertragungsstrecke
-
Anwendungsunterstützung (Application Support): Adressierung spezifischer Anwendungen und Verbindungen durch Port-Nummern
Segmentierung (Data Segmenting)
Eine Funktion von TCP besteht darin, den von den Anwendungen kommenden Datenstrom in Datenpakete bzw. Segmente aufzuteilen (Segmentierung) und beim Empfang wieder zusammenzusetzen. Die Segmente werden mit einem Header versehen, in dem Steuer- und Kontroll-Informationen enthalten sind. Danach werden die Segmente an das Internet Protocol (IP) übergeben.
Da beim IP-Routing die Datenpakete unterschiedliche Wege gehen können, entstehen unter Umständen zeitliche Verzögerungen, die dazu führen, dass die Datenpakete beim Empfänger in einer anderen Reihenfolge eingehen, als sie ursprünglich hatten. Deshalb werden die Segmente beim Empfänger auch wieder in die richtige Reihenfolge gebracht und erst dann an die adressierte Anwendung übergeben. Dazu werden die Segmente mit einer fortlaufenden Sequenznummer versehen (Sequenzierung).
Verbindungsmanagement (Connection Establishment and Termination)
Als verbindungsorientiertes Protokoll ist TCP für den Verbindungsaufbau und Verbindungsabbau zwischen zwei Stationen einer Ende-zu-Ende-Kommunikation zuständig.
Durch TCP stehen Sender und Empfänger ständig in Kontakt zueinander.
Fehlerbehandlung (Error Detection)
Obwohl es sich eher um eine virtuelle Verbindung handelt, werden während der Datenübertragung ständig Kontrollmeldungen ausgetauscht. Der Empfänger bestätigt dem Sender jedes empfangene Datenpaket. Trifft keine Bestätigung beim Absender ein, wird das Paket noch mal verschickt.
Da es bei Übertragungsproblemen zu doppelten Datenpaketen und Quittierungen kommen kann, werden alle TCP-Pakete und TCP-Meldungen mit einer fortlaufenden Sequenznummer gekennzeichnet. So sind Sender und Empfänger in der Lage, die Reihenfolge und Zuordnung der Datenpakete und Meldungen zu erkennen.
Flusssteuerung (Flow Control)
Bei einer paketorientierten Übertragung ohne feste zeitliche Zuordnung und ohne Kenntnis des Übertragungswegs erhält das Transport-Protokoll vom Übertragungssystem keine Information über die verfügbare Bandbreite.
Mit der Flusssteuerung werden beliebig langsame oder schnelle Übertragungsstrecken dynamisch auszulasten und auch auf unerwartete Engpässe und Verzögerungen reagiert.
Anwendungsunterstützung (Application Support)
TCP- und UDP-Ports sind eine Software-Abstraktion, um Kommunikationsverbindungen voneinander unterscheiden zu können. Ähnlich wie IP-Adressen Rechner in Netzwerken adressieren, adressieren Ports spezifische Anwendungen oder Verbindungen, die auf einem Rechner laufen.
Aufbau des TCP-Headers
Jedem Datenpaket, das TCP verschickt, wird ein Header vorangestellt, der die folgenden Daten enthält:
- Sender-Port
- Empfänger-Port
- Paket-Reihenfolge (Nummer)
- Prüfsumme
- Quittierungsnummer
- Flags
Aufbau des TCP-Headers TCP-Pakete setzen sich aus dem Header-Bereich und dem Daten-Bereich zusammen. Im Header sind alle Informationen enthalten, die für eine gesicherte TCP-Verbindung wichtig sind. Der TCP-Header ist in mehrere 32-Bit-Blöcke aufgeteilt. Mindestens enthält der Header 5 solcher Blöcke. Somit hat ein TCP-Header eine Länge von mindestens 20 Byte.
TCP-Header:
Schwächen von TCP
Eine Schwäche von TCP ist die Verzögerung durch den Verbindungsaufbau vor der eigentlichen Datenübertragung. Und nach dem Verbindungsaufbau mit TCP entstehen weitere Zeitverluste durch den Verbindungsaufbau mit den Protokollen TLS und HTTP. Da fragt man sich zu Recht, warum kann ein Verbindungsaufbau bzw. Handshake nicht für alle beteiligten Protokolle gelten.
Beim Protokoll Quick UDP Internet Connections (QUIC) werden Wartezeiten, die durch viele einzelner TCP-Verbindungen entstehen, durch Verschachtelung mit darüberliegenden Protokollen eingespart und sogar die TLS-Verschlüsselung integriert.
Neue I2P Version + offizieller Changelog steht nun auch auf der Downloadseite zur Verfügung.
https://geti2p.net/en/
RELEASE DETAILS
Changes
i2ptunnel: Support SHA-256 digest proxy authentication (RFC 7616) SSU2: Connection migration SSU2: Immediate acks SSU2: Enable by default
Bug Fixes
i2ptunnel: Fix IRC USER line filtering Installer: Fix path for Windows service, caused local eepsite to be broken Installer: Fix error on Windows when username contains a space NetDB: Database store message handling fixes NetDB: Fix reseeding when clock is skewed Router: Deadlock fix SSU2: Fix packets exceeding MTU SSU2: Fix ping packets less than minimum size SSU2: Fix handling of termination acks SusiDNS: Fix adding entry to empty address book SusiMail: Fix dark theme button icons UPnP: IPv6 fix Windows: Fix launching preferred browser at startup
Other
Deadlock detector improvements Debian: Change dependency from libservlet3.1-java to libjsp-api-java and libservlet-api-java i2psnark: Increase max pieces to 64K i2psnark: Add links to additional instances in the console Option to compress router logs Translation updates
Mich würde interessieren, ob die hier im Artikel erwähnte deanoymisierung in I2P auch mit den neuen Sicherheitsfunktionen der I2P Build 2.0.0 möglich ist und falls ja, ob diese durch die neuen Sicherheitsfunktionen erschwert wird?
Da dieser Angriff wie im Artikel beschrieben noch auf das ältere I2P Protokoll SSU abzielt.
Das müsste ein Wissenschaftler aufs Neue untersuchen, dann erst könnte man diese Frage beantworten, ob die Deanonymisierung noch immer möglich ist.
Nach etwa einem Jahr scheinen die verschiedenen Angriffsmöglichkeiten auf I2P von den I2P Entwickler nochmals erschwert wurden sein, zumindest was die Angriffe der wissenschaftlichen Arbeit betreffen.
Habe diese hier nochmal zusammengefasst:
-
Sybil-Angriff: Dies ist ein Angriff, bei dem ein Angreifer viele gefälschte Identitäten im Netzwerk erzeugt, um die Kontrolle über einen Teil des Netzwerks zu erlangen oder das Vertrauen anderer Knoten zu missbrauchen. Dieser Angriff ist für I2P eine Bedrohung, da es keine zentrale Autorität gibt, die die Identitäten der Knoten überprüft. I2P kontert diesen Angriff, indem es die Anzahl der Tunnel pro Knoten begrenzt und die Tunnelzuteilung zufällig macht.
-
Eclipse-Angriff: Dies ist ein Angriff, bei dem ein Angreifer versucht, einen bestimmten Knoten vom Rest des Netzwerks zu isolieren, indem er alle seine Verbindungen übernimmt oder blockiert. Dieser Angriff kann für I2P gefährlich sein, da er die Anonymität und die Verfügbarkeit der Dienste beeinträchtigen kann.
I2P schwächt diesen Angriff, indem es mehrere Tunnel pro Knoten verwendet und die Tunnel regelmäßig wechselt. -
Angriffe auf das Bootstrapping: Dies sind Angriffe, die versuchen, die Initialisierung eines neuen Knotens im Netzwerk zu stören oder zu manipulieren, indem sie falsche oder schädliche Informationen liefern. Dieser Angriff kann für I2P problematisch sein, da es keine vertrauenswürdige Quelle für die Netzwerkinformationen gibt. I2P versucht, diesen Angriff zu vermeiden, indem es mehrere Methoden für das Bootstrapping anbietet, wie z.B. die Verwendung von vorinstallierten Router-Infos, die Verbindung zu einem bekannten Freund oder die Verwendung eines Reseed-Servers.
- Traffic-Analyse: Dies ist ein Angriff, der versucht, die Anonymität der Knoten zu brechen, indem er den Datenverkehr im Netzwerk beobachtet und Muster oder Korrelationen findet. Dieser Angriff ist für I2P eine Herausforderung, da es schwierig ist, alle möglichen Beobachter im Netzwerk zu verhindern. I2P versucht, diesen Angriff zu vermeiden, indem es verschiedene Techniken anwendet, wie z.B. die Verschlüsselung und Verzögerung des Datenverkehrs, die Verwendung von Dummy-Paketen, die Vermischung und Aufteilung der Nachrichten und die Anpassung der Bandbreite.
Rein technisch gesehen, ist und bleibt dieser Punkt wohl die größte Herausforderung! Denn ein faules Ei im gesamten Konstrukt, vernichtet letzten Endes die komplette Hühnerfarm!
Nunja, die Sicherheit gegen Traffic Analyse hängt von mehreren Faktoren ab, wie z.B. der Anzahl und der Vielfalt der aktiven Router, der Länge und Qualität der Tunnels, die die Verbindungen bilden, die Verwendung von den Verschlüsselungen und Signaturen und den (zusätzlichen) Anwendungen, die man im oder mit I2P verwendet.
Ein recht ordentlicher Grundstein mit 2048-Bit ElGamal/ AES256/SHA265+ Session Tages Verschlüsselung und Ed25519 EdDSA / ECDSA Signaturen, die auch einer DPI-Zensur widerstehen, bilden eine gute Grundlage.
Im I2P-Messenger sind seit längeren einige Bürger aus China unterwegs und dies ist ein gutes Zeichen, dass I2P durch die Great Firewal der Chinesen dringt und eine Rückverfolgung nicht so einfach möglich ist, sonst hätten die chinesischen Members keinen regelmäßigen Austausch im I2P, ausgenommen es sind staatliche Einrichtungen oder Behörden aus China.