-----BEGIN PGP SIGNED MESSAGE----- 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@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].)
str4d
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi,
as I have said on the tor-dev channel, if you guys want a unique IPv4 address on a virtual machine I still have both available for you good people. It simply takes a gentle prod in the ribs for me to enable it and you can use and abuse it in any way wish you need.
Regards,
Phill.
On 2 November 2013 22:18, str4d str4d@i2pmail.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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@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].)
str4d
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux)
iQEcBAEBCgAGBQJSdXoiAAoJENXeOJaUpGWyBBMH/0c39pn97sBZvBj7HaMJAde2 ucn6Ug9vd41AmxNcOEhG65wpOrfB32sfnwI7DsRAYlOhjdxdquUl1yQHzTzs7NeG VLwRNe7e7Zv7VRj9uRp6t5+0YQU6++RkzhX5Jtn7l5W+3XYq0c4lRpSpwawP4NHN Zc9MveAU1tbsQqvhsFoYoJEsADpBj+97Xf0D05buUYMttjsmKv254HhGaLpuDCpv gEY3nBDHlHZqRziwxV7WmWPIsetdkATnmkUqcoCIPbZzJh2j6W3rZmHUieGU9OPC M3offV3ImZd/gSVcKW1rzDEEZh2mDcmg0XkwMbsEwc/LCn15y5jPk2yFlGpKKsE= =u2QY -----END PGP SIGNATURE----- _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Phill Whiteside -
str4d