Analysis of an Attack on an I2P User

The I2P network has been around since 2003, and over the years, it has accumulated rumors, misconceptions, and articles about vulnerabilities—many of which are now outdated. Before diving into the main discussion, let’s clarify some resolved issues you might still encounter. Don’t let them confuse you.

Common Misconceptions

Myth #1: I2P Doesn’t Scale Well

Some claim that I2P can’t handle a large increase in nodes and that the network will be paralyzed because the so-called “floodfill” nodes won’t manage the information flow. The myth suggests I2P only works while it’s unpopular, and as soon as the load increases, the network will collapse.

In reality, the number of floodfill nodes grows with the network, and not all floodfills are needed to access a specific hidden service. Each hidden service publishes its full address (called a lease set) to two floodfills closest by DHT (Distributed Hash Table), and these DHT coordinates change almost randomly every day. Each of these two floodfills then duplicates the lease set to three other logically closest floodfills. As a result, the lease set is published on at least four nearly random routers, which are then used to find the address of a specific site or hidden resource. In short: the network is distributed, and resources for processing lease sets grow with the total number of nodes. Since the myth about poor scalability first appeared, I2P has grown many times over and remains functional without any signs of floodfill overload. Additionally, a transition to new encryption is underway to further reduce the load on floodfills.

Myth #2: You Can Identify the Router Hosting a Hidden Service by Its Encryption Key

This theory is based on the idea that onion encryption in tunnels isn’t enough, and that end-to-end encryption with the router’s key is used, allowing someone to track tunnels by the key identifier. In reality, this threat was eliminated early in I2P’s development. Modern lease sets contain an encryption key that is not linked to the router. Each hidden service uses a unique key, so matching keys from different lease sets of the same administrator doesn’t provide any evidence that they’re on the same router.

Myth #3: I2P Tunnels Can Be Hijacked

Here, “hijacking” means not decrypting traffic, but identifying the tunnel owner. The attack requires as many routers as possible with good uptime to maximize their participation in transit tunnels. The idea is to wait until a victim’s tunnel consists mostly (or entirely) of malicious routers. Transit nodes don’t know the total number of routers in the chain, but tunnel length is three hops by default. If all three routers in a tunnel are controlled by an attacker, they can reasonably guess that the last node is the tunnel owner.

If an attacker intercepts a user’s outgoing tunnel, they could learn where the user is connecting if, by extreme luck, they also know the lease set containing the entry tunnel data of the hidden resource, matching the current destination. In reality, this attack is nearly impossible today, with tens of thousands of nodes in the network. Even if a tunnel is intercepted, you can’t be sure the suspected owner isn’t just another transit router. Such attacks are random, unpredictable, and very costly, with a negligible chance of success.

Reseed Attacks

The simplest way to disrupt I2P is to block reseed servers, which provide the initial network snapshot when a router is first launched. A reseed is an archive containing several routerInfo files—a package with information about random routers used to build the first user tunnels and start expanding the local network database. All reseed servers are run by enthusiasts, and their addresses are publicly available. Since they use domain names and known IP addresses, it’s easy to compile a list and block them centrally. However, making the first launch difficult does not mean blocking I2P’s operation!

To bypass blocks, I2P supports using a proxy when connecting to a reseed server, easily circumventing local ISP restrictions. Additionally, any router can be started with an existing network database, for example, copied from another I2P router. A new step in countering possible blocks is using additional encrypted communication channels. Currently, the Yggdrasil Network serves this purpose, allowing not only reseed access but also full I2P network use. For outsiders, Yggdrasil activity looks like a VPN connection. As of this article’s publication, I2P over Yggdrasil and proxy is only available in i2pd, which is another argument against the outdated Java router.

The second reseed manipulation scenario is intercepting the archive en route to the user to damage or replace it. HTTPS and cryptographic signatures protect against this. Reseed server certificates (cryptographic credentials) are distributed with the I2P router. After receiving the initial package, the router checks its signature. If it matches the certificate, you can be sure the reseed wasn’t tampered with.

Reseed server operators are regular users and enthusiasts. They don’t undergo any checks and usually remain anonymous. The community regularly checks the relevance of reseed servers, and if one fails, it’s removed from the list in the next I2P router release.

Sybil and Eclipse Attacks

Sybil and Eclipse attacks are similar in implementation. The idea is to flood the network with nodes controlled by an attacker, aiming to keep the user in a “sandbox.” Isolating routers don’t share information about regular nodes, preventing the user from escaping the blockade. This allows monitoring the list of resources the targeted user hosts or visits. To get information about a hidden resource’s entry tunnels, the attacker needs its lease set from the nearest floodfill, just as they need to publish their own lease set to be found.

If successful, all of the user’s tunnels and available floodfills are controlled by the attacker. The main difference: Sybil attacks aren’t targeted at a specific user, while Eclipse attacks aim to isolate a known target. Both require modified I2P routers and a high level of attacker expertise. Let’s examine the feasibility of these threats.

An Eclipse attack is practically unfeasible due to the reseed system, which is protected from interception. If a router starts with a copied network database (i.e., not from a public reseed, but from another I2P router), the source is assumed to be trustworthy. It’s logical not to use a startup package from an untrusted source. If an attacker poses as an enthusiast and runs a public reseed server, note that I2P routers use several independent reseeds, one chosen at random. This makes targeted attacks extremely unlikely and not worth the effort.

A Sybil attack aimed at general network monitoring seems more plausible with a malicious reseed. However, the cost outweighs the benefits. First, the attacker needs significant resources to introduce as many controlled nodes as possible. Second, they must develop software to flexibly aggregate data from these nodes. Third, analysis-focused attacks require a long duration, which is unlikely since the malicious reseed will soon be detected by the community. The most obvious sign is a stagnant or unusually low number of known routers in the web console. In a paranoid scenario, delete the entire local router database (in the netDb folder) and restart the router to trigger a new random reseed. If you suspect a compromised reseed, report it to the developer community. As of this article’s publication, no such attacks have been recorded.

Java Router Destination Attack

This last attack model is complex but critically dangerous if successful. The issue was disclosed by the lead I2Pd developer and is absent in the C++ router, but has long remained unpatched in the Java router. The model allows an attacker to determine that two or more endpoints are on the same router—effectively revealing that several anonymous entities are physically on the same computer. The vulnerability exists because all lease sets in the Java router are stored in one place.

The attack involves making a full request to a certain endpoint (destination), which responds and saves the attacker’s lease set. Then, a request is made to another endpoint, but the lease set for the response is not provided, so logically, there should be no reply. If a reply is received, the attacker can confidently conclude that the responding endpoint (which wasn’t sent a lease set) is on the same router as the first resource that received the lease set.

In I2Pd, the problem is solved simply and elegantly: each endpoint has its own lease set storage, inaccessible to other hidden services on the router.

Conclusion

Upon close examination, many frequently mentioned threats turn out to be either outdated or not as severe as pseudo-experts claim. Support open-source projects, report bugs and shortcomings. Free software often operates without funding or advertising, but with integrity. And remember: SMS verification during registration is not the norm!

Material based on the text and illustrations from the author.