Opened 5 years ago

Closed 20 months ago

#1375 closed defect (no response)

Audit I2CP for leaks of router-identifying information

Reported by: str4d Owned by:
Priority: minor Milestone:
Component: api/i2cp Version: 0.9.14.1
Keywords: Cc:
Parent Tickets:

Description

Because Tor has one control port for everything related to the tor process, there are anonymity issues within the threat model of isolating middleboxes and isolating proxies, which need access to some controls for Tor but not others. See https://trac.torproject.org/projects/tor/ticket/8369 for details.

I2P has always enforced strong separation of concerns between the router and clients via I2CP. Therefore it should be possible to run I2P in an isolating proxy setup, where the I2CP server port is exposed to the local network and clients can only connect outwards via tunnels created through it.

There is nothing in the I2CP docs to indicate that any router-identifying information is intentionally sent to clients. But if we audit I2CP and verify this is the case, it is valuable information for developers of isolating proxies, like Whonix, to have.

If it is not the case, we should make it so. I can't see any reason why an I2CP client should know (or care) about the real identity of the router that is managing its tunnels. It only needs to trust the router with knowing the plaintext of its communications (because I2CP client-to-I2CP client encryption has been disabled). This is okay because in an isolating proxy model, more trust is assigned to the router than the clients.

Subtickets

Change History (4)

comment:1 Changed 5 years ago by zzz

That's an interesting threat model.

Yes, end-to-end encryption was disabled in 0.6, July 2006. At the time, jrandom couldn't think of any reason not to trust the client or the router-client connection.

In recent years I've added some minor features to protect the router a little more. We now support I2CP-over-SSL and username/password authentication. We have much better I2CP error handling and sanity checks on the router side (good for client-side bugs but also helps in more hostile cases) and more coming in 0.9.16.

There is no router identifier in the I2CP protocol, it would be a 5-minute audit. To make the router/client separation even more clear, in 0.9.16 I am moving the router data structures (RouterIdentity?, RouterInfo?, RouterAddress?) out of i2p.jar completely. So they won't even be in our public API any more.

As far as a client deanonymizing his own router, that's trivial by setting zero-hop tunnel configuration. Sure, a router could enforce a minimum. But traffic analysis (at least in a small network) seems like it would get you there pretty quickly. Not sure it's a solvable problem.

comment:2 Changed 5 years ago by zzz

At least the following config options would have to be implemented and enforced per-client:

  • min tunnel length
  • max tunnel length
  • max tunnel quantity
  • max bandwidth in/out

There's also some trickery or corruption the client can do with leasesets. We'd have to lock that down, or perhaps pull LS signing into the router and hide all that from the client.

But I don't know if I2CP can ever be hardened enough to expose to untrusted users. Maybe SOCKS or SAM or BOB would be better for that?

Or have I misunderstood the question in the OP?

comment:3 Changed 4 years ago by zzz

  • Status changed from new to infoneeded_new

Yeah I think the larger threat model is having one client mess with another. I don't think we can hide the router from the client.

Assigning back to you for more info.

comment:4 Changed 20 months ago by zzz

  • Resolution set to no response
  • Status changed from infoneeded_new to closed
Note: See TracTickets for help on using tickets.