Can NAT traversal be Tor's killer feature? | Hacker News Reader

Can NAT traversal be Tor's killer feature?

gist.github.com

47 pointsobvio17117 comments

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.

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.

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

This is definitely part of the problem. I looked into tightly integrating Tor / Hidden Service connectivity into some apps, but was disappointed there aren't widespread libraries, and that you have to fall back to asking the user to install Tor separately. At least there is a bit of a control-plane API to configure Tor from your App over sockets.

One library I was able to find for Tor called Orchid: http://www.subgraph.com/orchid.html if you browser through the code it will give you a real appreciation for the complexity of the protocol. So after seeing that, I didn't feel so bad about the lack of Hidden Service libraries. But the current process of setting up a Hidden Service is definitely not for the average user.

Have you looked into WebRTC much? It supports arbitrary (text or binary) data transfer between browsers, in both TCP-like and UDP-like modes, with inbuilt NAT-busting (both STUN and TURN). It does NAT-busting rather than VPN, so it's faster than either Tor or a VPN.

So if the reason you wanted NAT traversal was "my (browser|game|filesystem) wants to share data with someone else's", WebRTC is a far easier answer, and is now available to most browsers[1] without extra software installs. It does involve a privacy loss of your connection details to the STUN/TURN server, but the signaling server cannot decrypt your (DTLS) communication.

If the reason you want a global LAN isn't those things, what is it?

[1]: Available outside browsers, too: see e.g. my Node WebRTC chat client -- https://github.com/cjb/serverless-webrtc -- or the native C++ API.

The signaling server, while unable to decrypt communications, has the inherent ability to record "metadata" about each connection, with to ability to create a peer association graph. Not a deal breaker, but worth mentioning. WebRTC is awesome.

More considerations at https://tools.ietf.org/html/rfc5766#page-55

That's true. If this is an issue you could avoid using a signaling server altogether, and instead exchange offer/answer via e.g. GPG-encrypted email.

I wonder if there are any designs for a signaling server/system that doesn't have this loss of privacy of connection information, or if you just very quickly end up reimplementing Tor when you try..

Good point. If any sufficiently complicated NAT traversal solution ends up containing an ad hoc, informally-specified, bug-ridden, slow implementation of half of the hidden services protocol, might as well put our efforts into building out Tor itself and get the privacy for "free".

Also, there's a wonderful open standard called ICE - http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ... - that 'properly' encapsulates STUN and TURN into a very effective NAT traversal mechanism.

IIRC, Google's Jabber/XMPP library - https://developers.google.com/talk/libjingle/- that was once actively maintained had an ICE implementation that also included access to Google's STUN/TURN relays but sadly this has gone unmaintained.

ICE is used by WebRTC. libjingle has been brought into Chromium, including STUN/TURN to Google's servers. So both of these things are now shipped in the browser; quite the opposite of being unmaintained.

I mean I haven't seen releases of libjingle anymore.

Here's a related way to maybe add a ton of new relays to the Tor network without having to go all "transparent through virtual network interface" right from the start:

1. Make a torrent tracker that serves out peer onion addresses (OAs?) instead of IPs;

2. Fork Popcorn Time, make it create a hidden service for itself and connect to the OA tracker;

3. Make the Popcorn Time fork also a relay by default. You'll add a lot of load to the network, so you have to give back.

Probably wouldn't be able to _stream_ anything, but otherwise should work.

This "Popcorn Tor" (too bad can't use the name ;)) could also soft-enforce some download limit based on the amount of traffic the user has relayed. Sane defaults and interface nudges can go a long way.

NAT traversal isn't a problem these days. The issue is bootstrapping the traversal. Use the hidden services to exchange real IPs and set up the VPN link to route around the slowness of Tor.

That could also work. You lose all the anonymity though, so only makes sense for when you need bandwidth and opt out of privacy. You could have separate virtual network interfaces for the different use cases.

I think this is kind of related to Geoffrey Goodell's argument from 2006 in

http://www.sobco.com/papers/tr-06-06.pdf

I was trying to remember who at Harvard had written about this and I think that's probably the report I was thinking of. Maybe I should also suggest his thesis

ftp://ftp.deas.harvard.edu/techreports/tr-12-06.pdf

Thanks, I'll read them up. Skimming through, I saw this: "We [...] have built a system we have deployed on the Tor anonymity network [8] and on PlanetLab [13]."

Do you know if it's still alive or what happened to it? Was it released/adopted at all?

Relevant: https://github.com/ipop-project/ipop-tincan

Libjingle is the underlying library of Google Talk and WebRTC implementations.

Reply on news.ycombinator.com