130 lines
7.2 KiB
Markdown
130 lines
7.2 KiB
Markdown
# eeProxy
|
||
Yet another standalone, contextual-identity aware proxy for i2p. This time
|
||
better organized and smaller. It is unfinished. An accounting of the extant
|
||
issues follows.
|
||
|
||
[I2P Link - Stream Isolation](http://trac.i2p2.i2p/ticket/1149)
|
||
[I2P Link - Shared Tunnels](http://zzz.i2p/topics/217)
|
||
|
||
For reference, the equivalent to these Tor SOCKS features are targeted.
|
||
|
||
- IsolateClientAddr
|
||
- Don’t share circuits with streams from a different client address. (On by default and strongly recommended; you can disable it with
|
||
NoIsolateClientAddr.)
|
||
- IsolateSOCKSAuth
|
||
- Don’t share circuits with streams for which different SOCKS authentication was provided. (On by default; you can disable it with
|
||
NoIsolateSOCKSAuth.)
|
||
- IsolateDestPort
|
||
- Don’t share circuits with streams targetting a different destination port.
|
||
- IsolateDestAddr
|
||
- Don’t share circuits with streams targetting a different destination address.
|
||
|
||
|
||
It doesn't fix [this matter long noted by the i2p project](https://geti2p.net/en/docs/api/socks),
|
||
but filtering might be added at some other layers to help generically connect
|
||
applications at a layer where it might be more useful. Those will be connected
|
||
to the SOCKS proxy and not part of it. HTTP, WebSockets and stuff.
|
||
|
||
Why this is/will be better than si-i2p-plugin
|
||
=============================================
|
||
|
||
It's all pretty broken right now. This is just "the plan."
|
||
|
||
Much, much smaller. I expect this will never rise to more than 2000 or so lines
|
||
of code, and that's a pretty roomy estimate. Right now it can do everything
|
||
si-i2p-plugin can(given a workaround due to an extant bug I'm going to fix after
|
||
I write this), one additional thing(See below), and is just ~600 lines of code
|
||
compared to ~7000 lines of code for si-i2p-plugin. A static executable is about
|
||
~5MB for eeProxy and takes seconds to build. A static executable of
|
||
si-i2p-plugin is about ~9MB for si-i2p-plugin and takes a couple extra seconds
|
||
to build.
|
||
|
||
Below: Persistent, per-site destinations are on-by-default. This means that
|
||
every site will see a different destination, *but* those sites will see the
|
||
same destination(and thus the same identity for you) until the keys for that
|
||
site are no longer present in the configuration directory. Don't just delete
|
||
them though, handling that is a thing that's not quite ready yet. If you need
|
||
a new identity for an eepSite, then stop eeProxy, delete the associated config
|
||
file, and restart eeProxy. The reason this works is because of the next thing.
|
||
|
||
Per-site tunnel prebuilding: Tunnel building is expensive, and the overhead of
|
||
si-i2p-plugin is largely down to this. My laptop is from 2006 and it seems
|
||
acceptable, but no reason not to try something that might be better. So the
|
||
persistent per-site destinations obviously have to store the keys across site
|
||
visits, that's one middlingly expensive bit that only has to be done once per
|
||
identity. The other thing it does is pre-builds tunnels for the identities
|
||
that you've already generated. That makes subsequent uses of eeProxy with the
|
||
same identities slightly faster. But in order to do all this properly it needs
|
||
to do at least two other things:
|
||
|
||
Tor-like isolation and a control interface. Applications should be able to tell
|
||
it to create a new identity tree for them, at this creation time, they will
|
||
*optionally* be allowed to use other's shared tunnels, but not by default and
|
||
only if they have chosen to share them, which is also not the default. The use
|
||
of this feature isn't going to be encouraged, but it might be convenient for
|
||
some highly planned setups.
|
||
|
||
Sane defaults, but offer optimization via post-configuration. si-i2p-plugin took
|
||
a brute-force approach, which isolated all tunnels and tore them down forever
|
||
after a short inactivity period. With eeProxy, the sites start out with a very
|
||
conservative set of proxy settings, but can be configured after the fact so that
|
||
they use new settings during the next pre-build. This makes it possible to
|
||
optimize tunnels generated by eeProxy but makes the configuration files very
|
||
sensitive information. Frankly they were already though. *Note to self to*
|
||
*consider some way of overriding accidentally or maliciously configured*
|
||
*settings, perhaps by setting minimums for things like tunnel length which are*
|
||
*enforced by the application regardless of configuration.*
|
||
|
||
And lastly, it will also need to be hooked up to a slightly more complicated
|
||
http proxy than I had originally thought. When you visit a new site you'll
|
||
be presented with probably 2-4 options before proceeding:
|
||
|
||
New Site Configuration Page:
|
||
[*] - Pre-Build tunnels for this eePite(Default on)
|
||
*[] - Use shared tunnels for this eepSite if available*
|
||
*[] - Accept address helper from $site*
|
||
(Proceed) (Generate new ID and proceed to destination)
|
||
[ ] - Show/Hide Advanced Client Tunnel Options
|
||
|
||
All of this ranges from 0-75% done at this point.
|
||
|
||
Other cool stuff I'll probably be able to do: UDP support, CONNECT support,
|
||
BIND support, custom addresshelper namespaces resolving to services/networks
|
||
running inside i2p. *And maybe something cool and dangerous.*
|
||
|
||
|
||
WARNING
|
||
=======
|
||
|
||
taken from i2p-projekt.net
|
||
|
||
SOCKS and SOCKS proxies
|
||
The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are supported. Enable SOCKS by creating a SOCKS client tunnel in i2ptunnel. Both shared-clients and non-shared are supported. There is no SOCKS outproxy so it is of limited use.
|
||
|
||
As it says on the FAQ:
|
||
|
||
Many applications leak sensitive
|
||
information that could identify you on the Internet. I2P only filters
|
||
connection data, but if the program you intend to run sends this
|
||
information as content, I2P has no way to protect your anonymity. For
|
||
example, some mail applications will send the IP address of the machine
|
||
they are running on to a mail server. There is no way for I2P to filter
|
||
this, thus using I2P to 'socksify' existing applications is possible, but
|
||
extremely dangerous.
|
||
And quoting from a 2005 email:
|
||
|
||
... there is a reason why human and
|
||
others have both built and abandoned the SOCKS proxies. Forwarding
|
||
arbitrary traffic is just plain unsafe, and it behooves us as
|
||
developers of anonymity and security software to have the safety of
|
||
our end users foremost in our minds.
|
||
Hoping that we can simply strap an arbitrary client on top of I2P without auditing both its behavior and its exposed protocols for security and anonymity is naive. Pretty much *every* application and protocol violates anonymity, unless it was designed for it specifically, and even then, most of those do too. That's the reality. End users are better served with systems designed for anonymity and security. Modifying existing systems to work in anonymous environments is no small feat, orders of magnitude more work that simply using the existing I2P APIs.
|
||
|
||
The SOCKS proxy supports standard addressbook names, but not Base64 destinations. Base32 hashes should work as of release 0.7. It supports outgoing connections only, i.e. an I2PTunnel Client. UDP support is stubbed out but not working yet. Outproxy selection by port number is stubbed out.
|
||
|
||
See Also
|
||
The notes for Meeting 81 and Meeting 82 in March 2004.
|
||
Onioncat
|
||
zzz.i2p
|
||
If You Do Get Something Working
|
||
Please let us know. And please provide substantial warnings about the risks of socks proxies.
|