

Can NAT traversal be Tor's killer feature? - obvio171
https://gist.github.com/obvio171/73122ba490c864644792#file-can-nat-traversal-be-tor-s-killer-feature-md

======
cyphunk
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.

~~~
obvio171
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.

------
zaroth

      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](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.

------
cjbprime
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](https://github.com/cjb/serverless-
webrtc) \-- or the native C++ API.

~~~
hideo
Also, there's a wonderful open standard called ICE -
[http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...](http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment)
\- 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/-](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.

~~~
cjbprime
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.

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

------
obvio171
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.

~~~
obvio171
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.

------
XorNot
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.

~~~
obvio171
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.

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

[http://www.sobco.com/papers/tr-06-06.pdf](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

~~~
obvio171
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?

------
chatmasta
Relevant: [https://github.com/ipop-project/ipop-
tincan](https://github.com/ipop-project/ipop-tincan)

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

