Meshbird – Distributed private networking(github.com)
github.com
Meshbird – Distributed private networking
https://github.com/meshbird/meshbird
55 comments
Just took a quick look at the crypto implementation. It uses AES-256 in CBC mode but..... without an authentication tag (HMAC).
Also known as "The Cryptographic Doom Principle".
https://moxie.org/blog/the-cryptographic-doom-principle/
https://moxie.org/blog/the-cryptographic-doom-principle/
I hadn't come across that post that I can remember; a very nice explanation by Moxie. Thanks.
There is an official (albeit experimental) NaCl implementation for Go which would probably have both been simpler and stronger to use: https://godoc.org/golang.org/x/crypto/nacl
We are working on AES-GCM encryption.
Development seems to be.. on hold, at the very least. The last commit was almost 6 months ago (2016-08-23), and the most recently closed issue was closed over 8 months ago (2016-06-06), and before that a year ago (2016-02-22).
How is this doing discovery of other nodes? Says it is fully decentralized but just doing a `meshbird new` to get a key and then running `MESHBIRD_KEY="key" meshbird join` doesn't explain the discovery mechanism to me. Haven't dug into it much though.
> Technologies used
> DHTThanks!
It sounds like you figured it out from that...but I'm having trouble. Does it do discovery the first time you attempt to connect or something?
We are using DHT https://en.wikipedia.org/wiki/Distributed_hash_table.
Each node announce some key in DHT network, that represents hash of shared secret key.
Each node announce some key in DHT network, that represents hash of shared secret key.
Hey! I'm MeshBird's author. Feel free to ask a questions.
Keep up the good work! Much appreciated
@rickette posted this:
"Just took a quick look at the crypto implementation. It uses AES-256 in CBC mode but..... without an authentication tag (HMAC)."
Any response?
"Just took a quick look at the crypto implementation. It uses AES-256 in CBC mode but..... without an authentication tag (HMAC)."
Any response?
Good point. We are going to implement AES-GCM encryption based data transfer. Why AES-GCM to solve HMAC missing? Because Go have low-level asm optimisations. This is open way to full utilization of 10G/40G networks.
Seriously, I'd advise that you implement an HMAC today, and implement GCM tomorrow — using raw CTR mode really is that dangerous. And make sure that you never ever ever reuse IVs, ever.
This sort of thing is incredibly dangerous. Props to you for coming up with a great UX, but crypto is very, very difficult to get right.
This sort of thing is incredibly dangerous. Props to you for coming up with a great UX, but crypto is very, very difficult to get right.
Soit's like zerotier?
It's a bit misleading to say no gateways are required. As far as I can tell it uses STUN/TURN for NAT busting. When NAT busting does not work (in case of corporate firewall for example), communication falls back to the TURN server as a relay.
IIRC according to google a few years ago, something like 10-20% of STUN/TURN traffic needs to be routed over the TURN relay server.
This is a gateway.
IIRC according to google a few years ago, something like 10-20% of STUN/TURN traffic needs to be routed over the TURN relay server.
This is a gateway.
I don't fully understand purpose of this project after visiting the website and other links provided in comments. How is it different from regular VPN?
Edit: found explanation on ZeroTier blog: https://www.zerotier.com/blog/?p=833
Edit: found explanation on ZeroTier blog: https://www.zerotier.com/blog/?p=833
1. now central server
2. node autodiscovery across Internet
For example, you can easily build Cassandra, MongoDB or PostgreSQL cluster on top of Meshbird networking in different countries.
For example, you can easily build Cassandra, MongoDB or PostgreSQL cluster on top of Meshbird networking in different countries.
Does anyone here have any experience with other distributed VPNs?
I run Wormhole (hosted "distributed" VPN / Overlay Networking / You name it), which uses SoftEther behind the curtains: https://wormhole.network
Check out wireguard: https://www.wireguard.io/
Wireguard supports roaming but it's not distributed in a p2p global sense.
True. tinc: https://www.tinc-vpn.org/ is another option for distributed VPN
But if you're ok with discovery going through master/server and then connecting directly to peers for traffic, I'd stick with Wireguard.
But if you're ok with discovery going through master/server and then connecting directly to peers for traffic, I'd stick with Wireguard.
PeerVPN – Open-source peer-to-peer VPN
https://news.ycombinator.com/item?id=9025792
https://news.ycombinator.com/item?id=9025792
Tinc (http://www.tinc-vpn.org) works well for me and can do meshing.
gvpe is similar to tinc, and I wrote up a small piece about using it on Debian here:
https://debian-administration.org/article/695/Joining_dispar...
https://debian-administration.org/article/695/Joining_dispar...
I used to use n2n:
https://github.com/meyerd/n2n
Haven't found anything else quite like it.
https://github.com/meyerd/n2n
Haven't found anything else quite like it.
Why did you stop using it?
Well, it seems to be stalled, for starters.
Running a VPN between only 4 machines wasn't that useful, and it needs a central server. I quite like Meshbird's idea of using DHT instead. If it ever evolves to improve its crypto and setup, I might take it up instead.
Running a VPN between only 4 machines wasn't that useful, and it needs a central server. I quite like Meshbird's idea of using DHT instead. If it ever evolves to improve its crypto and setup, I might take it up instead.
".. it needs a central server."
There is a PDF by the original author that explains the difference from "VPNs".
A reachable IP address and a TAP device are the only requirements.
For example, two edges can also be supernodes. A third party supernode would only be needed for the initial connection. Once connected, then each can use the supernode run by the other. The third party is no longer needed. No central server.
As for DHT, who runs the DHT bootstrap server?
Do DHT users run their own bootstrap servers?
Do users exercise any control over the DHT? Who does?
There is a PDF by the original author that explains the difference from "VPNs".
A reachable IP address and a TAP device are the only requirements.
For example, two edges can also be supernodes. A third party supernode would only be needed for the initial connection. Once connected, then each can use the supernode run by the other. The third party is no longer needed. No central server.
As for DHT, who runs the DHT bootstrap server?
Do DHT users run their own bootstrap servers?
Do users exercise any control over the DHT? Who does?
By central server I mean a referral hub, yes. But I just couldn't keep one up reliably (in the sense that I didn't want to, since the mesh had to be fairly dynamic in my case).
cjdns works for me and seems quite secure as a private, distributed VPN. It automatically assigns an unforgeable IPv6 address to each node:
https://github.com/cjdelisle/cjdns
https://github.com/cjdelisle/cjdns
ZeroTier: it connects my laptop, my VDS, and my behind-two-NATs home machine pretty efficiently. That is, e.g., when my laptop is connected to the home wi-fi, the zerotier interface seems to exchange packets directly with the home machine.
Presence of an Android client is important for me. Auto-reconfiguation in a new network (laptop on a public wi-fi, phone on mobile networks) is nice.
"Peer-to-peer discovery" is not important for me, that is, I'm OK with my nodes discovering the network via a control center. (You can self-host the control center.)
Presence of an Android client is important for me. Auto-reconfiguation in a new network (laptop on a public wi-fi, phone on mobile networks) is nice.
"Peer-to-peer discovery" is not important for me, that is, I'm OK with my nodes discovering the network via a control center. (You can self-host the control center.)
I've used DMVPN extensively, but mostly on (Cisco) BFR's.
The IPsec stack that comes your OS probably supports host-to-host mesh when suitably configured.
Not a VPN and not distributed, but probably worth to mention anyway: Tor hidden service + SSH. Works very well.
Why not just use cjdns?
The real win here is clearly that abomination of a GoPher
"Better encryption" in the roadmap and then "curl ... | sh".
No. Thanks.
No. Thanks.
"curl ... | sh" is absolutely fine. If you want to complain about something, complain about the fact that the URL being used is an http URL instead of an https one.
If you want to complain about something, complain about the completely pointless fragmentation of the Linux ecosystem that pretty much mandates "curl|bash" to ship software for "Linux."
You say that like advanced packaging tools weren't pioneered by "Linux"...
They were. That's not the problem.
The problem is tools -- plural. Users think "I have Linux, where do I get the Linux version?" You have to provide arcane instructions for how to add a package repository on Every. Single. Linux. Distribution.
Or you can script it and users can run a command. Still painful, but less so for the user.
As far as the distributions themselves go: they are harder to get software into than the Apple App Store. The rules are arcane and the docs either barely exist or are on wikis that have not been updated in over a decade. The whole process is unnecessarily arcane beyond belief.
The problem is tools -- plural. Users think "I have Linux, where do I get the Linux version?" You have to provide arcane instructions for how to add a package repository on Every. Single. Linux. Distribution.
Or you can script it and users can run a command. Still painful, but less so for the user.
As far as the distributions themselves go: they are harder to get software into than the Apple App Store. The rules are arcane and the docs either barely exist or are on wikis that have not been updated in over a decade. The whole process is unnecessarily arcane beyond belief.
"curl | sh" is not in itself any less secure than "npm install" or "go get", but it is often a good indicator of a project that takes usability more seriously than security. IMO, it's also seen as "the new way" to do installs, and implies a lack of respect for the fodgy old way to do things (e.g. with a package manager).
> … is not in itself any less secure … takes usability more seriously than security.
You're contradicting yourself. If it's not any less secure, then how does using it mean you're not taking security securely? And you're also treating usability as if it's not important, when in fact usability is very nearly the most important part. If your software isn't usable, then nobody will use it, and if nobody is using it then it doesn't matter how secure it is.
You're contradicting yourself. If it's not any less secure, then how does using it mean you're not taking security securely? And you're also treating usability as if it's not important, when in fact usability is very nearly the most important part. If your software isn't usable, then nobody will use it, and if nobody is using it then it doesn't matter how secure it is.
Many of these scripts actually install through package managers, dockers curl | sh like a year or two ago basically just set up an apt repo and ran some apt commands. I think the hurdle they're gunning for is having X number of distro targets and the explanation cost for a user that just wants to jump in.
At least, that's how I've read it to be.
At least, that's how I've read it to be.