I2P support/integration

[str4d]

This ticket is about figuring out what is needed to support I2P Android, either on its own or in tandem with Orbot. Some users would greatly benefit from being able to force all connections through I2P Android (users who want to only use I2P services), while others would prefer to send .i2p requests (e.g. from browsers) through I2P Android and all others through Orbot. This is similar to how Orfox will in future support both Tor and I2P URLs.

I2P supports SOCKS proxy tunnels already, and has done for some time. However, this requires configuration by the user in I2P Android before being able to use it. If orWall had I2P integration (and could open its own tunnel as required), overall usability would improve.

I am working on an Android AAR library which is intended as a drop-in library for client apps to utilize I2P Android. Anything needed on the I2P side will most likely end up in there.

[cjeanneret]

@str4d here are some ideas:

• i2p provides some API (intent) in order to request configured tunnels and usage (port 5096 for HTTP, port 5097 for IRC and so on)
• orwall request information from this intent in order to provide new configuration options:
  • select an app and force it through i2p only
  • configure a transparent proxy (http -> socks5 for example) for some tunnel, via netcipher library

Regarding the "redirect .i2p URL to i2p", I think this won't match orwall goal. Less there's a way to resolve addresses on two levels (first tor, then i2p) and i2p network has a dedicated internal ip range (10.10.0.0/16 for example), it will be hard to do that using iptables. MAYBE via some vpnService, but I'm not really sure this is doable (not to say "secure enough to meet users needs").

Hence, android AAR library is needed in order to go forward — any ETA? Can you provide some git repository so that I can already give it a try in a dedicated branch of orwall?

I've already opened an issue on netcipher regarding the orbot port configurations — this one isn't that needed, as default ports are quiet obvious and people don't change them that much.

Thanks for you feedback, advices and info :).

Cheers,

C.

[str4d]

What I2P provides (both on desktop and Android) is an API called I2CP, allowing any number of clients to talk to the router. The Android AAR library that I have so far wraps the internal parts of I2CP so the client can use our standard Java API. You can build this "bare-bones" library from the I2P Android source in the client subproject.

Unlike Orbot (and Tor in general) which has a single SOCKS proxy that all apps get configured to use, I2P is set up to enable I2P-aware apps to create their own tunnels as they require them, giving developers much more flexibility over how they want to use I2P.

However, I don't think this is quite what you need for your app, as it stands. You require a live local SOCKS proxy port that you can configure iptables to send data to. What I think you need is an Intents API for interacting with I2PTunnel, which itself uses our standard Java API and I2CP to help users create a variety of tunnel types. (It is intended for use with legacy apps that don't know or care about I2P, which includes iptables. You could alternatively use the Java API and copy the SOCKS proxy code from I2PTunnel to manage it yourself).

I could see this being useful for different levels of API abstraction: developers who want minimal I2P coupling could use the I2PTunnel Intents API, while developers who want more control and flexibility could use the standard Java API via the full client library.

So, as you would be the first user of this Intents API, you have the privilege of influencing its design :) What calls would you want to make? The first ones that come to mind for me are:

• Fetch a list of configured tunnels
  • filtered by I2PTunnel type (Standard, HTTP, SOCKS, etc.)
  • filtered by name?
  • Could this have inter-app anonymity issues? Probably a non-issue, the I2PTunnel interface is not exactly secure.
• Create a new client tunnel of a particular type, with some basic config options
  • This would be saved by I2PTunnel, and the user would see it if they go to the I2PTunnel settings.
  • This probably should not be allowed to be automated without user interaction, otherwise apps could spam I2PTunnel with tunnels and overload the router or device.
  • Maybe the Intent could launch I2PTunnel's tunnel creation wizard, pre-configured, so the user only has to review and accept.
• Delete a tunnel?
  • I don't think this should be an option, at least not without user interaction.

[cjeanneret]

Thanks a lot for your complete answer, @str4d :)

What I see as "basic required features" for orwall:

• list existing I2PTunnels
  • filter by type
  • filter by status (up, down) if available (I think one can configure tunnels and NOT activate them… ?)
  • by name would be great in order to provide a better user experience in the "client" app

Speaking more generally, the other proposals make sens: we want to be able to create new tunnels, through the wizard (good point in order to prevent bad app wanting to create mess in the network), as well as, maybe, delete them (through a dialogue in order to avoid messing app again).

Regarding security: I don't think listing existing tunnels may be a problem; it may become one if an app can list them AND use them in order to listen to traffic, meaning the connection between an app ant the tunnel isn't secure (that's why I proposed to build transProxy using ciphernet — if i2p already propose this feature, I'd rather let it manage it and, why not, provide some hints for security if needed [and if I have the knowledge]).

If you have any starting code, I'll be glad to test it (though my knowledge in java is… well, consider it's a zero-knowledge, more or less) and give you feedbacks.

Cheers,

C.

[str4d]

Connections between an app and I2PTunnel are not by default secured, because the local machine is assumed to not be compromised (and if it was, an adversary would have full control of the router). Android is a different case because it provides inter-app security boundaries, so with a malicious app installed, listening over the connection becomes more preferable.

From a general perspective, if a developer is concerned about traffic sniffing on the Android device between their app and I2P Android, using our upcoming client library and our Java API is a Good Idea(:tm:), because the client library uses Android LocalSockets to communicate with I2P Android which bypass the network stack, decreasing latency and preventing simple sniffing.

From your app's perspective I don't know how a localhost port (necessary for iptables) could be protected from sniffing while being used as a captive network portal, but maybe it doesn't matter in that case.

In any case, here is our intro to I2P application development, which has some sample code for using the Java API. It further explains why writing I2P-aware code is a good idea.

[cjeanneret]

Hmm, ok. Basically, if I understand correctly the codes, I shall just use net.i2p.client.streaming.I2PSocketManager in order to get socket information.

Regarding sniffing: as iptables can use the app UID, we may say something like:

iptables -t nat -I OUTPUT -m owner --uid-owner <appuid> -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-port <SOCKS>
iptables -I OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN --dport <SOCKS> -m owner --uid-owner <appuid> -j ACCEPT

This would allow only to access the port — I'm not sure it may actually prevent sniffing but, at least, it would allow only selected app to access the port. Best would be to encrypt connection between app and tunnel entry, of course, but this shall be done at client level.

I'll do some tries on my own in order to play a bit with the current library, that's the best way to learn (at least for me ;) ).