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

@cyphunk
Copy link

cyphunk commented Jul 11, 2014

I've run an IRC bouncer and SSH reverse tunnels over Tor for years. Not for the privacy but just for the ease of use. Also it reduces concerns with maintaining up to date linux hosting. While the risk of my .onion being discovered through the cat-and-mouse game that is de-anonymizing .onion's may permit some 3 letter agency to discover and root my host I at least reduce the attack service drastically by completely removing internet script kiddies from the threat model. So their is a security benefit in addition to the NAT transversal. The NAT transversal really makes a different and very easy reverse workflow possible. With some simple haggling with scripts and SSH you can reverse almost anything that is low bandwidth. I totally agree there is something to the ease of use provided that services have not fully explored yet.

And since most single-peer to home services never require an exit node bandwidth is never an issue. File transfer, remote mail, even a reverse tunnel to use a home IP as your exit node, all work with little to no bandwidth constraints. I really believe there are services to be built on this ease of use. Things that utilise these features without requiring one understand SSH reverse tunnels and the likes.

Finally, somehow I think the more services built on such a model the better we will understand how to fix some of the major flaws of the internet as a whole. Namely discrimination based on GeoIP comes to mind. If the internet were built in this manner instead of addressing a service I could have it address me through my own .onion reverse I think location discrimination would become a much more complex task. GeoIP is becoming much more fundamental. as the xkeyscorerules100.txt shows GeoIP is no longer just something used by media companies to prevent someone watching TV out of country and is today used to determine citizenship and basic civil liberties.

@hsribei
Copy link
Author

hsribei commented Jul 11, 2014

Those are very clever uses of this idea, glad to hear more people have thought of and run with it.

I hadn't given GeoIP much thought yet, but you make an excellent point. GeoIP determining citizenship and basic civil liberties is indeed crazy scary. Can't get more "the architecture is the truth" and "code is law" than that.

Let's hope someone smarter than me can figure out a good way to make this interface easier to use and more widespread, be it with a virtual network interface or not. It could just be a well-design, dead-simple API for building serverless/p2p apps on top of hidden services without knowing Tor, or a streamlined way to do tunneling as you're doing.

@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