Skip to content

Instantly share code, notes, and snippets.

@hsribei
Last active July 12, 2018 19:15
Show Gist options
  • Star 31 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
  • Save hsribei/73122ba490c864644792 to your computer and use it in GitHub Desktop.
Save hsribei/73122ba490c864644792 to your computer and use it in GitHub Desktop.
Can NAT traversal be Tor's killer feature?

Can NAT traversal be Tor's killer feature?

tl;dr: how about a virtual global flat LAN that maps static IPs to onion addresses?

We all know the story. Random feature gets unintentionally picked up as the main reason for buying/using a certain product, despite the creator's intention being different or more general. (PC: spreadsheets; Internet: porn; smartphones: messaging.)

It's already happening

Exhibit 1: Ricochet IM (https://ricochet.im) uses onion addresses (each client runs a hidden service) as a sort of static anonymous IP address and, because it's static, it's the user's identity too, in a p2p/serverless chat app. It's dead simple, works like a charm behind the firewall at work, and protects metadata, which no other chat app/protocol I know does.

Exhibit 2: OnionShare (https://onionshare.org/) does the same for file sharing, and it's actually a much easier user experience to send large files this way than any other. Why? "Static anomyous IP" (onion address) and NAT traversal because all tor hidden services work by making outgoing connections to Tor relays and don't need any open ports.

Those are two great apps that, unlike Tor Browser (which I love very much, but hear me out), improve the user experience, through Tor, in comparison with the mainstream (OnionShare even more so). The user might not even care about security or anonymity, it's just a better experience, period.

You don't have to convince people to make sacrifices in the name of privacy, you just have to show them something they want.

Like water

That's when natural demands kicks in and suddenly you're not pushing water uphill anymore, you've changed the landscape and it flows in the direction you want. Like when Tesla made electric cars that people buy despite being electric, not because of it.

As good as Ricochet and OnionShare are, they still had to go through the trouble of integrating hidden services themselves.

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.

[ZeroTierOne (http://redecentralize.org/interviews/2013/07/30/02-adam-zerotierone.html) does this, but doesn't worry about privacy.]

The only thing better than serving the privacy-conscious is serving privacy to those who don't even know they want it.

Demand vs capacity

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.

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

P.S.: you can follow me @obvio171 on Twitter.

P.S.2: more comments on Hacker News: https://news.ycombinator.com/item?id=8018213.

P.S.3: more comments on tor-talk: https://lists.torproject.org/pipermail/tor-talk/2014-July/033815.html (OnionCat seems to already implement something like what I describe.)

P.S.4: follow up post: https://gist.github.com/obvio171/addb26214a8c159f84a8#file-putting-the-tor-back-in-torrent-md

@tobia
Copy link

tobia commented Aug 5, 2016

This is a brilliant idea, but one issue that springs to mind is that onion addresses are 80 bit long (AFAIK) while the IPv4 address space is 32 bit (minus loopback and other special addresses), up to maybe 48 bit if we restrict each client to a single TCP port.

Therefore, IMHO any sufficiently generic "OnionVPN" would need to target IPv6 exclusively, which might restrict its usefulness with legacy software, such as old games.

Other than that, I think it's a brilliant idea! Bravo!

@jbenet
Copy link

jbenet commented Aug 5, 2016

Yes, it definitely could. And it would be great if this use case drove the creation of tons of Tor nodes. 😄 👍 I'd love to see that happen.


For performance though, an overlay that can be optimized to match the underlying physical topology will be much faster/better. Privacy focused routing (Tor, I2P) makes it hard to achieve great perf, because we cannot optimize for latencies without leaking lots of data about nodes. Today, most constructions have to trade off latency for privacy.

I encourage you to check out other alternatives, too, like cjdns and fc00, which are directly IPv6 compatible:

In the IPFS Project, we think cjdns and fc00 are a much better fit for this, and have already begun work on them.

@jbenet
Copy link

jbenet commented Aug 5, 2016

Oh and, all of this needs work! \o/ For anyone interested, there's a lot of great work happening right now across all these projects, jump in and help. We have the chance to "un-break" the end-to-end principle in the next year.

@Xe
Copy link

Xe commented Aug 5, 2016

https://www.onioncat.org/ already done by these guys

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment