[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

I2P lacks stream isolation support


#1

Problem:

I2P does not have stream isolation support meaning that HTTP clients send the same X-I2P-Dest* headers to every eepsite visited - which allows adversaries running colluding eepsites to track user visits across sites.

Workaround:

New headers are generated when the I2P daemon is restarted so its recommended you restart I2P as often as possible to avoid profiling over long stretches of time.

Fix:

An I2P user is working on a plugin that uses SAM interface to retrieve sites over different connections. He said that it would be simple two day job.


https://www.reddit.com/r/i2p/comments/579idi/warning_i2p_is_linkablefingerprintable/
http://i2p2piszzzndhfvr.onion/doku.php/start

The above will be posted on the Whonix I2P wiki page.


#2

Boy I did say that didn’t I. :grimacing:

Posting in this dead topic to make a couple clarifications:

Destinations for the HTTP proxy expire periodically during periods of inactivity. I think the default was like 30 minutes, I’ve got mine turned off entirely and can’t remember. It shouldn’t be necessary to restart the router to get a new HTTP proxy destination in most circumstances. In light of this, I think the bigger concern than profiling by HTTP proxy destination is retroactive linking of expired HTTP proxy destinations by correlating them to another identifier or set of identifiers. A malicious social networking site which logged X-I2P-Dest headers of logged-in users could hypothetically do this, for example. One thing I am doing is trying to see how useful a browser fingerprint would be for this purpose.

As I understand it, the header is actually added in at the server side for HTTP tunnels only. That means that the client can’t just ‘not send it’ and the server always has a destination, although contextually separating destinations and making them exist for a very short term seems to be possible to do in a pretty reasonable way. It’s also easy for a server to not add in the header if it doesn’t want to or doesn’t use it, but it still knows the destination. It merely chooses not to forward it to the service.

As for the modified proxy I never got around to SOCKS in the original version(HTTP works fine though) but I’ve got some time off coming up and I’m going to do a rewrite on top of some of the other primitives I’ve developed. I definitely don’t think it will take as long this time. :wink: