[tor-dev] .i2p address support in torsocks

str4d str4d at i2pmail.org
Sat Nov 2 22:18:59 UTC 2013

Hash: SHA512

On 11/03/2013 06:58 AM, David Goulet wrote:
> Apparently, I failed to put the person in CC :).

I subscribed to tor-dev after talking with you :)

> On 02 Nov (13:47:56), David Goulet wrote:
>> On 02 Nov (19:25:42), Maxim Kammerer wrote:
>>> On Sat, Nov 2, 2013 at 5:58 PM, David Goulet
>>> <dgoulet at ev0ke.net> wrote:
>>>> For now, it would only be .i2p address support (like .onion).
>>>> In torsocks, it's not that difficult to support both
>>>> addressing.
>>> Does I2P's SOCKS proxy work in a way that's similar to Tor?
>>> Other proxies in I2P are protocol-specific — e.g., ports
>>> 4444/4445 for HTTP(S) and 6668 for IRC. I am quite sure that
>>> protocol-specific local I2P proxies like HTTP and IRC strip
>>> sensitive information, so providing the user with an easy
>>> access to .i2p services via SOCKS might be the wrong thing to
>>> do. The SOCKS information page [1] is rather scarce on details
>>> of what actually goes on inside the proxy, however.
>> For now, it's simply detecting an .i2p address, opening a
>> connection to the i2p daemon and pushing the request there. The
>> person at i2p I talked to told me that it's quite straight
>> forward and no special SOCKS5 mangling would be needed.

Specifically, the I2P tunnel runs a local SOCKS server socket that
handles the standard SOCKS4/4a and SOCKS5 protocols, and any data to
be sent to the .i2p address is forwarded to an I2P socket. The
standard (unfiltered) SOCKS client tunnel only forwards data between
the SOCKS and I2P sockets, this should be functionally similar to Tor.
We also have a variant that filters IRC traffic for anonymity (using
SOCKS to connect to I2P IRC networks is a common use case), but this
occurs during the forwarding step, the SOCKS server socket is unchanged.

If a non-.i2p address is detected, the SOCKS server opens a SOCKS
client connection to a configured SOCKS outproxy. This is designed to
enable chaining to Tor, but it has some bugs that need fixing (this
not working reliably is why I looked into torsocks). The configured
SOCKS outproxy also needs to be listening inside I2P, which adds
latency. If torsocks supported separate SOCKS ports for each
configured .suffix, a user could run both I2P and Tor locally and use
them in parallel instead of in series.

>> If there is some work to do on the protocol side like you
>> mention, I would imagine that the i2p daemon does it or else...
>> well there is a problem :).

If there are problems with our SOCKS implementation, they can be fixed
(or implemented - I2P supports datagrams, but SOCKS UDP is not yet
implemented). For filtering, it is up to the user to decide if they
want to use a filtered SOCKSIRC tunnel or an unfiltered SOCKS tunnel,
but it should not affect torsocks usage. (I want to make it possible
for different filters to be written and used, but the user still needs
to be made aware of the potential dangers to anonymity of generically
SOCKSifying applications [1].)


>> Putting someone from i2p in CC:
>> Cheers! David
>>> [1] http://www.i2p2.de/socks.html
>>> -- Maxim Kammerer Liberté Linux: http://dee.su/liberte 
>>> _______________________________________________ tor-dev mailing
>>> list tor-dev at lists.torproject.org 
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>> _______________________________________________ tor-dev mailing
>> list tor-dev at lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Version: GnuPG v1.4.14 (GNU/Linux)


More information about the tor-dev mailing list