https://github.com/zerotier/toss
... and another less magical one:
11–20 of 192 posts
https://github.com/zerotier/toss
... and another less magical one:
How is the 16 bit wormhole code secure against brute force?
Also, Piknik: https://github.com/jedisct1/piknik
Also, you only need to send the public part of an SSH key to the remote end to set up future keyed connections to that system.
This seems like a solution with very narrow problems to solve.
Also, Piknik: https://github.com/jedisct1/piknik
Trusting the baked-in rendezvous server would seem to be the most obvious security "nit," which could be addressed by compiling and running your own server. But out-of-the-box, that would seem to be a weak-point for MitM attack.
Waiting for the security nits, but this looks awesome and I have use cases for it every week
This reminds me of the great tool http://www.fefe.de/ncp/ , which seems like the same thing only without the cryptographic authentication!
* at least one side has a public IP address * both sides are on the same (private) LAN * a TURN-like "Transit Relay" server that I run
That transit server hasn't gotten a worrysome amount of traffic yet, but it's a potential scaling problem. (Fortunately the two sides can offer their own transit servers, and they negotiate the one to use, so it's also not a difficult scaling problem to address).
In the long run I'm hoping to get some NAT-hole-punching tools, maybe WebRTC, to reduce the need for the transit relay somewhat. Also in the long run, if both sides are using Tor, then one of then can run an onion service, which gets you the NAT-punching for free.