[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Can NAT traversal be Tor's killer feature?
On Thu, Jul 10, 2014 at 10:41 PM, str4d <str4d@xxxxxxxxxxx> wrote:
> On 07/11/2014 12:12 AM, Helder Ribeiro wrote:
>>
>> If there is a virtual network interface that transparently maps
>> static IPs to onion addresses, all sorts of things could benefit
>> from the backward compatibility (old games, IP-based voip,
>> screensharing, real-time collaborative writing, etc.) and new ones
>> could be built a *lot* more easily.
>
> OnionCat [0] provides this functionality via a layer 3 VPN. It works
> with Tor Hidden Services (ocat) and I2P tunnels (gcat [1]), by
> calculating a unique IPv6 address from the hidden service ID or I2P
> Destination. This has the advantage that you can give an IPv6 address
> to an application and it will resolve correctly anywhere.
That's awesome! Didn't know about it, thanks to you and Lunar for
pointing it out. Will research further.
>
> OnionCat is not as user-friendly as I think you would like, primarily
> because it requires that the Tor HS or I2P tunnel is already set up.
> But further integration could be done (certainly with I2P, because all
> tunnels automatically have a Destination).
This seems like an excellent Summer of Code job :) I'm not at all
familiar with any tor-related codebase and I'm a security noob, but
this is something I could try putting together.
>
> One downside to this method is that there is a possibility of address
> collisions. I am not familiar with the particular algorithm OnionCat
> uses to map IPv6 addresses to .onions, but in the I2P case at least,
> the IPv6 address space is not large enough to hold all possible I2P
> B32 addresses (which are 52 characters long). The Tor proposal for
> next-gen HSs outlines a format for new .onions that is nearly
> identical to I2P B32s, and will have the same problem.
>
> The solution that I2P is considering for this is to remove the
> requirement for a global IPv6 <-> .b32.i2p mapping, and instead use a
> local ephemeral mapping on a virtual interface combined with a local
> DNS resolver. This would enable backwards compatibility for
> applications that support hostnames.
Good point. If complete transparency isn't possible for all cases, it
might be for a good enough subset.
Otherwise, having a dead-simple library that makes it easy for
developers to abstract out the IP parts and allow using hidden
services instead could be a close second.
>
> As an aside, most of the applications that you mention generally use
> UDP packets, which Tor does not yet support (AFAIK). I2P does support
> datagrams.
>
> str4d
>
> [0] https://www.onioncat.org/
> [1]
> https://www.cypherpunk.at/onioncat_trac/browser/trunk/i2p/Garlicat-HOWTO
>
>>
>> [ZeroTierOne
>> (http://redecentralize.org/interviews/2013/07/30/02-adam-zerotierone.html)
>>
>>
> does this, but doesn't worry about privacy.]
>>
>> Of course massive use would probably crush the current network,
>> but uptake would be gradual, and I imagine demand has a greater
>> power to drive capacity than the other way around.
>>
>> The only thing better than serving the privacy-conscious is
>> serving privacy to those who don't even know they want it.
>>
>> I'm nowhere near an expert and I could be just talking out of my
>> ass, so please let me know if this is completely stupid and would
>> never work. Thanks!
>>
>> Cheers, Helder
>>
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJTv0BwAAoJEIA97kkaNHPnUmEP/1XreMW+mivJDpOmpex++7CM
> XtodR25/fY7aDp4LLU808HokK5pNo88Lmh6KiT6S41A2CNV5KIfpp8+d5yU2Ux4+
> Lx7mfWaWSxxEbK/GbnrJVEbRb0JK/csniBAoMB3rRXgBrN7nypEzUBvwcB3gHYxy
> cce3RndWwp2+6P8xQHtonvtSUQCVIdDrjt84h0//9URrypw+BVW1zP94c0eaHQF/
> 49uzseP/KnJyOxrpw66RaEqhMhQYK6ZgwVVR1xYLvIsAHTTnNFNef4uf9FtDGYj7
> 2/incGTnaiV0paxH2UEYC6gkSqb/Kdek/4fo7ve5SeowbjmC+Bxe6Za8sIr0c6N6
> 5EWjNtZXeMwyNvsz4TNps9lnQVly+4QGbT7kZwtDB6UkFxYnRaJ8E8qAJmOKYcyO
> Y2mV25HbOw1g1F+tfUdzMA+fbXLq2ww1bt5qJifRG7cgVng0kPSIS8dMdnzAUbZ/
> oGRiMWHX15Opt1wlCpVQ5ZUC4htLxnYr+IJomXGa8Qk5aI3qwZXFeUhCLvxJvtgk
> TvCIEilFURA/3vNP6QMFeto8zuLZflwexSvLUFlSMjZhg11xSuV/iob3RqzBwpzV
> BBrPd2QkQ7tIbiAfq3/ZZM/cICdivw5slgSUJw114S4iig+Ub4RXPQWbnwWvWUnB
> W250BYiuyljFtX6N9exI
> =YXw1
> -----END PGP SIGNATURE-----
> --
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
--
Apoie a transparÃncia no voto eletrÃnico:
http://www.vocefiscal.org
Blog:
http://www.discor.de
PGP:
CED4 BB85 FBC5 661E 56B2 3D5C DCE5 C2D2 FC19 843C
https://keybase.io/obvio171
Ricochet IM:
ricochet:jqprzgdxxqk2g63b
Code is politics.
Se vocà usa a WikipÃdia, doe mensalmente para mantÃ-la no ar:
http://bit.ly/wikipedia-assinatura-mensal
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk