Access by Key: Protecting I2P Sites from Unwanted Visitors

DDoS (Denial of Service) attacks are a common way for competitors to disrupt each other. The simplest form involves overloading the network channel so that real users can’t reach the server or experience frustrating delays. A more sophisticated approach is to create artificial load on services that eagerly consume server resources, such as a flood of requests that trigger database queries or other resource-intensive operations, overloading the machine.

There are many services designed to protect clients from suspicious network activity. Typically, these services analyze even encrypted traffic and perform browser analytics to reliably detect malicious activity. As a result, attackers are presented with a CAPTCHA or are blocked from accessing the target resource altogether.

But what about hidden networks, where users don’t have IP addresses and analyzing encrypted traffic is fundamentally unacceptable? In this article, we’ll look at a unique way to protect against DDoS attacks in the I2P network and discuss the technology of lease sets with authorization.

Encrypted Lease Sets: A Foundation for Privacy

This article builds on the topic of encrypted lease sets, which serve as an additional privacy tool for hidden resources. To connect to an anonymous site, the I2P router contacts a directory node, which returns a lease set—information about encryption keys and the service’s inbound tunnels. This means the floodfill (directory node) operator can learn about your resource simply by observing the lease sets published on it. Using an encrypted lease set prevents this possibility.

However, you can’t assign a human-readable short address in the “.i2p” zone to such a resource, so this option isn’t widely used and is reserved for cases of real necessity. But what if you’re hiding your resource and one of your trusted users leaks the address? The private service you tried to conceal could again become vulnerable to DDoS attacks and other potential issues.

Encrypted Lease Sets with Authorization

The ultimate solution is an encrypted lease set with authorization, which can only be decrypted with a personal key in addition to the full address. This concept is unique because it allows the administrator to block malicious users at the network protocol level.

Think about it: protection from all kinds of attacks not through firewalls, server settings, CAPTCHAs, or third-party services, but at the network level itself. A user not authorized by the administrator can’t access the server because they don’t receive the lease set containing information about the hidden resource’s inbound tunnels. As a result, attacks are impossible—the resource is simply out of reach for the attacker.

Types of Lease Set Authorization in I2P

The I2P protocol supports two types of lease set authorization: by password and by key. Passwords are simpler but not much harder to use than real cryptography. Keys are far more secure than passwords, eliminating even the theoretical possibility of a successful brute-force attack. For a respectable user, passwords are passé.

How It Works

Encryption keys are generated by the client, and the public key is then given to the administrator of the target resource. The server encrypts the lease set with each public key in the list. When a user receives the encrypted lease set, they try to decrypt it with their private key. If their public key wasn’t used for encryption, the lease set remains inaccessible.

Minimal Tunnel Configuration with Encrypted Lease Set and Authorization

[SUPER-HIDDEN-SERVICE]
type = server
host = 127.0.0.1
port = 8080
inport = 80
keys = site.dat
signaturetype = 11
i2cp.leaseSetType = 5
i2cp.leaseSetAuthType = 1
i2cp.leaseSetClient.dh.NNN = User:PublicKey

• NNN – a random integer (used to specify multiple keys)
• User – the username or nickname for the administrator’s convenience (optional)
• PublicKey – the public key in base64 encoding

Using a Password Instead of Keys

Authorized lease sets use x25519 encryption keys, which can be generated with the i2pd-tools utility.

On the client side (the user’s tunnel), you only need to specify one additional parameter:

i2cp.leaseSetPrivKey = PrivateKey

where PrivateKey is the private key in base64 encoding.

Testing and Security

For demonstration, I commented out the key on the client side and restarted the I2P router. No matter how long I waited, my computer couldn’t find the inbound tunnels for the specified endpoint. If you monitor the router at the debug level, you’ll see that the lease set does arrive, but its contents remain a mystery.

Similarly, the resource administrator can impose restrictions. If a disgruntled user tries to retaliate against the admin, they won’t succeed. Even knowing the address won’t help.

Current Limitations and Future Prospects

Currently, authorization is only available for individual tunnels. The main user proxy, typically used for browsing the network, doesn’t support this parameter yet. However, this feature is expected to be added soon, allowing private resources to be used without extra hassle—just specify your key once in the main router configuration file.