Der Angriff wird mit der neusten I2P Version 2.3.0 nicht mehr möglich sein.
Da diese neue I2P Version einen Fehler fixt, der den Angriff überhaupt erst ermöglicht hat.
This release contains fixes for CVE-2023-36325. CVE-2023-36325 is a context-confusion bug which occurred in the bloom filter. An attacker crafts an I2NP message containing a unique messageID, and sends that messageID to a client. The message, after passing through the bloom filter, is not allowed to be re-used in a second message. The attacker then sends the same message directly to the router. The router passes the message to the bloom filter, and is dropped. This leaks the information that the messageID has been seen before, giving the attacker a strong reason to believe that the router is hosting the client. This has been fixed by separting the bloom filter’s functionality into different contexts based on whether a message came down a client tunnel, an exploratory tunnel, was sent to the router directly. Under normal circumstances, this attack takes several days to perform successfully and may be confounded by several factors such as routers restarting during the attack phase and sensitivity to false-positives. Users of Java I2P are recommended to update immediately to avoid the attack.
Im Zuge der Behebung dieses Kontexts-Verwirrungsfehlers wurden einige Strategien überarbeitet, um defensiv zu kodieren, gegen diese Art von Lecks. Dazu gehören Optimierungen am netDb, die zinsbegrenzenden Mechanismen und das Verhalten von Flutfill-Routern.
DETAILS: I2P 2.3.0
Changes
- netDb: Throttle bursts of netDB lookups
- Sybil/Blocklist: Allow users to override blocklist expiration with an interval
- DTG: Provide an API for extending DTG with a plugin
- Addressbook: add notbob’s main addressbook to the default subscriptions.
- Console: Add Ramble and notbob to console homepage
Bug Fixes
- Fix replay attack: CVE-2023-36325
- Implement handling of multihomed routers in the netDb
- Fully copy new leaseSets when a leaseSet recievedAsPublished overwrites a leaseSet recievedAsReply
1 „Gefällt mir“
Ist das überhaupt sinnvoll, dass der Router die empfange ID erstmal an den Filter weiterleiten muss, bevor das System dann bemerken kann, dass die ID zweimal genutzt wurde?!
Müsste nicht, meines Erachtens, der Analyst (also der Bloom-Filter) VOR dem Router sitzen und quasi wie eine Firewall, die doppelte ID erst gar nicht mehr an den Router ranlassen…?
Vllt habsch da ja etwas misbegrepen… 
Deine Frage scheint in der neuen I2P Version zum Teil oder bzw. auf eine andere Art gelöst worden zu sein.
Besonderheit der neuen I2P-Version 2.4.0, die gestern veröffentlicht wurde:
This release, I2P 2.4.0, continues our effort to improve the security and stability of the I2P network. It contains significant improvements to the Network Database, an essential structure within the I2P network used for disovering your peers. The congestion handling changes will improve network stability by giving routers the ability to relieve congested peers by avoiding them. This will help the network limit the effect of tunnel spam. It will also help the network heal during and after DDOS attacks. The NetDb changes also help secure individual routers and the applications that use them. Routers can now defend against attackers by separating the NetDB into multiple „Sub-DB’s“ which we use to prevent information leaks between applications and the router. This also improves the information available to Java routers about their NetDB activity and simplifies our support for multihoming applications. Also included are a number of bug-fixes and enhancements across the I2PSnark and SusiMail applications. Wir empfehlen wie immer, baldmöglichst auf die neue Routerversion zu aktualisieren. Ihrer eigenen Sicherheit und dem Netz ist am besten gedient, wenn Sie stets die neueste stabile Version von I2P verwenden.
VERSIONSDETAILS
Änderungen
Router: Restructure netDb to isolate data recieved as a client from data recieved as a router
Router: Implement handling and penalties for congestion caps
Router: Temp. ban routers publishing in the future
NetDB: Lookup handler/throttler fixes
i2psnark: Uncomment and fix local torrent file picker
Fehlerkorrekturen
i2ptunnel: Exempt tunnel name from XSS filter (Gitlab #467)
i2ptunnel: Fix gzip footer check in GunzipOutputStream (Gitlab #458)
SAM: Fix accept after soft restart (Gitlab #399)
SAM: Reset incoming socket if no subsession is matched (Gitlab #456)
https://geti2p.net/de/
1 „Gefällt mir“
Das kam gerade in unserer Telegram-Gruppe:
Apropos Dezentralisierung. Bei LibTorrent wird offenbar daran gearbeitet I2P zu unterstützen, damit würden dann auf einen Schlag sehr viele LibTorrent basierte Torrent Clients anonym Ende2Ende verschlüsselt im I2P Darknet Seeden und downloaden. Der content aus dem „normalen“ public torrent wäre damit dann in I2P automatisch auch verfügbar. Anonymes Torrenting wäre dann auch ohne VPN möglich. https://github.com/arvidn/libtorrent/pull/7831 Sehr spannende Entwicklung, mal sehen wie es damit weiter geht.
Heute früh kam dann als Antwort:
I2P ist dafür bekannt sehr langsam zu sein. Aber das wäre für viele wohl verkraftbar wenn es save ist. Einfach auf einem Raspi 24/7 durchlaufen lassen… Oder auf einem VPS. Mit Tribler (anyonmer Torrent Client) hab ich derzeit bei Tests mit 3 Hops für die Anonymisierung so 20-500KB/s für Torrents mit vielen Seeds. Da Tribler auf LibTorrent basiert, wird das I2P Netz in Zukunft voraussichtlich ebenfalls zusätzlich mit unterstützt werden. Für Streaming Anwendungen wird es sicher deutlich zu langsam sein, für alles andere aber evtl. ganz brauchbar.
Das bringt es gut auf den Punkt. Langsame Transfers lässt man dann einfach über Nacht laufen. Das wäre dennoch interessant, solange das Angebot groß genug und die Angelegenheit sicher ist.
…unbelievable…!
Also sagen wir mal, im Durchschnitt vielleicht nur 100 kb/s! Und das natürlich nur bei genügend Seeds.
Ist den I2P-Flitzpiepen die heutige Größe der meisten Torrents überhaupt geläufig? Games zwischen 40 bis 150 GB, Filme (2160p) zwischen 10 bis 30 GB, untouched um die 60 GB, Serien-Packs mit teilweise mehreren hundert GB etc. pp.
Ein Pack mit z.B. 250 GB hat erfahrungsgemäß natürlich auch einige wenige Seeder, dafür zumeist mit potenten Roots dahinter.
Wenn also wirklich alles top läuft bei I2P, kommen so 8,5 GB in 24 Stunden zusammen! Diesen Wert halte ich aber selber für reine Theorie, so wie ich das Netzwerk kenne…!
Bei einem 100 MB großes Audio-File könnte es reichen, um überhaupt p2p-Member hinterm Ofen damit hervorzulocken!
Hinzu kommt auch noch, dass ca. 80% der Nutzer auf einem ALT alles über Seedboxen und Roots abwickeln - Diese können die nicht einfach abschalten (was die sowieso nicht wollen!), da sonst der ganze „Web-Seed“ fehlen würde!! Theoretisch müssten diese das aber, weil bei solchen I2P-Geschwindigkeiten ein Web-Seed sinnbefreit wäre…!
Soviel dazu liebe I2P-Jemeinde
