
ZeroTier: Network Virtualization Everywhere - luu
https://www.zerotier.com/index.html
======
vmp
There's a (slightly hidden) public network called "Earth" with ID
8056c2e21c000001, discovered a few interesting hosts already (by using non-
intrusive avahi-browse):

28.204.184.27:6667 - IRC server identifying as "nagisa.yasashiisyndicate.org"

There's also a couple o' macbooks and, for a few minutes, someone advertised
their EPSON L110 Series printer but it vanished as quickly as it emerged. :)

So far I love it, seems like a viable replacement for Hamachi/Tunngle, the
Windows Client is rather ugly but functional, had no issues on Arch Linux
(built from source). Kudos.

~~~
api
Earth is slightly hidden because it's an experimental feature, but way back
when I started the project it was the point.

I found that most users wanted private networks, so I added network IDs and
certificates of authorization. But I still wanted to maintain the original
vision in there somewhere.

------
sneak
Ugh, yet another L2 VPN project that misuses non-rfc1918 (that is, assigned)
address space for their pet project.

Just... don't.

~~~
abcd_f
> Just... don't.

Let's hear the alternatives.

I'll give you 10 peers, each on its own RFC1918 subnet. You give me a flat
addressing scheme that doesn't involve NAT and IP6, requires no manual
configuration on peers' part and keeps them on a single connected (in routing
terms) network, so that broadcasts and multicasts work. Go!

~~~
KaiserPro
MPLS from a big ISP....

~~~
abcd_f
How exactly? Connect these three, for example -

    
    
      Peer 1: 192.168.0.111/16
      Peer 2: 172.16.0.222/12
      Peer 3: 10.0.0.333/8

~~~
yebyen
10.0.0.333 <\- this one is going to present a problem, I can tell you right
away ^_^

~~~
abcd_f
Whoops :)

------
roghummal
ZT PR is in overdrive! Woooooooo. The ham-handed way they've done it has
endeared me to them.

And maybe I thought the State of NAT posting was pretty good.

~~~
api
I'm the author and I'll take that as a complement... I think.

My take on really slick polished valley hipster corporate pr is if you've got
the resources to pull that off, sure, do it.

But if you don't it's like a bad special effect in a movie, usually worse than
no special effects at all. As they say in that field if you don't have the
flash it's all gotta be in the script.

------
zrail
I can see two immediate uses for this:

* Private backhaul network for my VPSs, useful for things like ssh, deploys, monitoring, metrics, and log aggregation

* Private network that I can set up between my laptop and my parents' desktop and fix things via VNC without having to pay for a dedicated service.

The lack of perfect forward secrecy is sort of a bummer, but for my purposes
it should be fine.

------
rwinn
The uninstaller is awesome! The service detects when you trash the app and
uninstalls itself. Well done

------
AlyssaRowan
No forward security yet? Hold off on this until it has that.

Still uses supernodes, too. May be interesting once it's matured a bit and
been redesigned, however.

According to djb (author of these algorithms) you shouldn't really be
persisting keys for longer than _minutes_ , let alone indefinitely.

~~~
tptacek
I'm not clear what you're trying to say with that last sentence. I didn't look
carefully (beyond the reference to NaCL) but I assume this is using Salsa20
keyed by Curve25519. Neither of those algorithms are any more "exhaustible"
(to coin a term) than AES or static DH, both of which are obviously capable of
providing security in normal situations more or less indefinitely.

I assume you must be referring to something other than the security longevity
of a Salsa20 key.

~~~
zrail
Curve25519, ed25519, and Salsa20 in 12-round mode:
[https://github.com/zerotier/ZeroTierOne/wiki/ZeroTier-One-
Se...](https://github.com/zerotier/ZeroTierOne/wiki/ZeroTier-One-Security-
FAQ#what-algorithms-does-zerotier-one-use-and-how-does-it-use-them)

~~~
tptacek
Elliptic curves don't have a round structure. Reduced-round Salsa20 keys
aren't secure for only minutes (or hours, or days, or months).

~~~
zrail
Sorry, I was just copy/pasting from the FAQ so you'd have more context (not
the OP nor the developer of ZT). I don't know enough to know what the
difference between "round structure" and "20 rounds of mixing"[1] is, but I'd
love to find out. Are there better references than that wiki page?

[1]:
[http://en.wikipedia.org/wiki/Salsa20#Cryptanalysis](http://en.wikipedia.org/wiki/Salsa20#Cryptanalysis)

~~~
tptacek
Most ciphers are iterated.

They define a core transform, which nonlinearly combines key material with
plaintext on a bit-by-bit basis and provides "confusion" and "diffusion".

You can think of modern cipher design as analogous to RISC computers. A
designer has a choice: they can make a very strong transform function, or they
can make a very simple transform which is weak by itself, but strong when
repeated. The latter approach dominates modern cipher design.

Modern ciphers execute the transform (the "round function") many times. They
take a key and expand it into subkeys, then use those subkeys with successive
invocations of the round function, feeding the (gradually strengthening)
ciphertext back through the cipher each time.

Curve25519 and ed25519 aren't ciphers. They are two different ways to use
elliptic curve math in cryptography; the former implements Diffie Hellman key
agreement in the mathematical domain of a specific secure curve, and the
latter implements public key signatures in that same domain. Neither mechanism
is suitable for encrypting data; they're used as tools to get two parties to
agree to a cipher key to use to encrypt the actual data.

In TLS, for instance, Curve25519 might negotiate an ephemeral key between the
server and the client (so that nothing would persist to disk that could be
scooped up by NSA later and used to decrypt the session when it ends).
Something like ed25519 could be used to sign the key exchange to make it
impossible to MITM the session. The ephemeral key would get plugged into
Salsa20, which would perform the actual encryption. It's Salsa20 that has the
round structure.

Salsa20 wants 20 rounds, but the last 8 of those rounds are for extra
security; the author believes it to be secure at 12 rounds, and nobody has
disproved that, or has any reason to believe he's wrong. Salsa20 was designed
for performance, and the cost of Salsa20 rounds is low, so 20 rounds was a
pragmatic, cheap hardening mechanism.

On the other hand, the performance difference between reduced-round Salsa20
and real Salsa20 isn't significant, so that was indeed a goofy choice† on
their part. Salsa20 is very, very fast. Not to mention: bulk crypto in general
--- AES in CTR mode, for instance --- is also very fast.

I'm not sticking up for this particular project; just reacting to the idea
that NaCL would need to be rekeyed frequently.

† _(I 'm taking it on faith that they actually are using Salsa20/12; I didn't
look carefully.)_

~~~
chipsa
You can use Curve25519 as a cipher. It's just fairly slow, like all PKC. It's
something like 600k cycles for 32 bytes, while AES is around 30 cycles for 8
bytes.

~~~
tptacek
What specific construction are you thinking of?

------
Rhapso
This is painfully close to something that could be much better. Sadly this
"p2p" system is strongly centralized. I cannot make a private network without
zero-tier's authorization. I cannot add nodes to a private network without
zero-tier's authorization. If zero-tier servers fail or the company dies, the
network goes with it. Because the strong centralization, future viability of
the network hinges on a single small companies continued existence. I cannot
use this to build anything meaningful. It could only serve as a competitor to
other vpn providers, not an improvement over the status quo.

~~~
zrail
It's almost completely open source[1]. The only component that isn't open is
the web interface itself, but there's complete documentation on the internal
data structures, how to run a super node, and how to reconfigure the clients
to serve up those super nodes instead of the ZT-provided ones.

[1]:
[https://github.com/zerotier/ZeroTierOne](https://github.com/zerotier/ZeroTierOne)

~~~
Rhapso
I rather happy about that, it saves me a lot of work. I've already cloned the
repo on github (and a few local machines). Essentially I currently plan on
unwrapping their administration system and switching to a shared secret model.

------
thinxer
I tried this it's really really simple to set up (than openvpn tinc etc).
However NAT traversing is still a hard problem and I cannot get online behind
two NATs.

~~~
api
My guess would be that one is symmetric. Some symmetric-NAT-busting tricks are
coming in future versions.

------
huhtenberg
The exact same idea as Hamachi, but with different business model. It'd be
interesting to see how this develops.

~~~
dmd
What _is_ the business model (considering the use of supernodes)?

~~~
api
Right now it's charging for the convenience of setup and administration on
zerotier.com. You can run your own "netconf master" and create your own
networks, but it requires some system administration and Redis database
wrangling.

Generally the people who will pay you are the people who want convenience,
like business users, and the rest are people who won't ever pay you anyway.

The supernodes are not part of the business model. That architecture just
exists to make the system fast and secure by providing managed anchor points.
All traffic is end-to-end encrypted so the supernodes can't see traffic
content.

~~~
dmd
Ah, I see. I didn't even see that they were charging at all. Now I do.

------
thesorrow
I'm behind two NAT myself and it's impossible to traverse them :O

------
nickthemagicman
Is there a centralized server on their end that all my data goes through?

~~~
zrail
Most of the time, no. The first packet of a given connection will hit a
supernode (one of four machines run by ZeroTier) to open up the NAT ports, but
after that everything is point to point.

Except in the case of an overly restrictive firewall that doesn't allow
outgoing UDP on port 9993, in which case every packet is tunneled over port
443 through one of the supernodes.

That said, every packet is encrypted with NaCL so that situation is less
concerning. Just slower.

