Decentralized VPN Written in Go
github.com
github.com
- symmetrical crypto with shared key across all clients, letting any VPN client act as any other client
- no PFS (straight AEAD with AES-GCM)
- alternatively, sketchy home-grown AES-CBC crypto that doesn't seem to be authenticated and as such allows for replay attacks and whatnot
- home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
- static routing (ie. no way for a client to decide what prefixes to announce at a given time without updating the centralized config)
- no support for roaming clients like phones or clients behind NAT (currently just depends on being able to send UDP datagrams to a preconfigured remote address)
There's probably other things I missed, especially crypto-wise.
I'd stay away from this (at least for now) and use something like wireguard or tinc instead.
"written in go" comes up 540 times in the search results, vs only 196 times for "written in javascript" even though the latter is way more common than Go.
I think what is going on is that the number of times you get these "written in" postings is somehow a function of the inverse of market share and how convinced practitioners are that the language in question is so good it should be used more widely. And some timing factor.
I had expected Rust to have more "written in" articles. It has a very dedicated following, but it is struggling a bit to gain more mainstream acceptance. Go meanwhile is getting to where it is in very widespread use for a broad applications (mostly server stuff). So I had expected there to be more "written in" articles for Rust than Go as Rust needs more evangelizing.
Perhaps if we lay out the articles on a timeline we see something interesting, but I suspect my hypothesis was a bit off.
I view you as correct about the market share, but incorrect about "language so good it should be used more widely". Not that Go or Rust devs don't believe that.. However, I don't think that's why these posts get upvoted. At least speaking for myself I love seeing the language it's written in.
As a Rust focused dev (for fun and profit) clearly I don't like Go posts because I believe it's the best language and all of my code should be ported. Yet I do like Go posts. Likewise I like Rust posts. I like Go posts because, like Rust, I know it will be an easy install. It will be something active, growing and "modern". I view these growing and modern languages to have more active contribution to the core project (if it's a good project of course).
I'm less interested in tools written in Python because I've had enough of difficulty in the past with Python installations that I just don't even care enough to bother. I also am less interested in a cool project written in some (I don't mean Python) other old and "dying" language. I have trouble envisioning contributions being high and trajectory reaching any critical point. Those things are important I think.
Language matters to me. It's not going to make or break a project to be written in something "odd" - but it's definitely of interest. For good or bad.
These are all my views.. most of it not fact. Please take it as such :)
But I don’t much care for how the Python community has failed to produce a language, practice and tool chain that plays nice with users. It is a somewhat selfish and anti-social language environment that forces users to care about things they shouldn’t have to care about.
As a user, it may not matter, but in this case the link is to a Github repo with 0 releases sent to a community of people who are probably more likely than average to be interested in the technical details. In that sense the question may rather be what makes JavaScript so special that it needn't be mentioned. After all, to even run it I need a special runtime environment (e.g. nodejs or a javascript enabled browser).
So for me at least, being written in Go is absolutely a pro.
The same can of course be said for software written in Java and C#, except their bloated runtimes make them resource hungry and include fun side effects like human-noticeable GC pauses.
The home-grown crypto in this tool makes it rather unappealing, though.
:/
> no support for roaming clients like phones
This isn't that uncommon. I think OpenVPN might not support that either.
> or clients behind NAT
:(
That problem should be solved by signatures or at least a chain of one to one key exchanges. But having a shared key sounds bad.
> - no PFS (straight AEAD with AES-GCM)
What does the cipher and AEAD have to do with PFS,I thought that was a key-reuse problem?
> - alternatively, sketchy home-grown AES-CBC crypto that doesn't seem to be authenticated and as such allows for replay attacks and whatnot
Yup,home grown sounds kinda bad but I don't see the peoblem if they just replicated the process with their own code without modifying how it works and avoid IV reuse.
> - home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
Same as before.
> - static routing (ie. no way for a client to decide what prefixes to announce at a given time without updating the centralized config)
Sounds like a feature request. PR?
> - no support for roaming clients like phones or clients behind NAT (currently just depends on being able to send UDP datagrams to a preconfigured remote address)
Again, a PR would be nice,any project adds features as they grow.
You have good critique but I don't think any of this means the project or quality is utterly bad. Issues and PRs will help them a lot I am sure but your first point about shared keys does bother me a lot.
> Yup,home grown sounds kinda bad but I don't see the problem if they just replicated the process with their own code without modifying how it works and avoid IV reuse.
> > - home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
> Same as before.
For both of these, my general thought is that they're massive crypto code smells - implementing things yourself when a vetted library exists is just not something you do for secure code. If we can see these crypto issues already, there's going to be more. Maybe it'll be implementation bugs, maybe conceptual architecture issues - but I'd bet on this not being a complete list. So even if these bugs aren't exploitable they're indicative of something deeper.
The sketchy, home-grown AES-CBC isn't "kind of bad". It's unauthenticated CBC. That's completely broken.
You don't PR a VPN from cryptographically secure to cryptographically sound. The cryptography is most of the point; if it isn't there, it's not going to get there by committee.
I understand that you know crypto extremely well but how can you say "It's unauthenticated CBC. That's completely broken." ? Using CBC without authentication is certainly broken but that only means you have to use a MAC with CBC. A MAC is NOT part of CBC and lack of MAC usage is a criticism that has nothing to do with their CBC implementation.
> They're not saying AEAD has anything to do with PFS. They're saying that the only encryption they have is (at best) the AEAD, without a kex.
If that'a what they meant then it makes sense. I read it as if AEAD was thought of by them as an alternate to PFS.
I don't like that mindset. Usually an open source contributor/creator shares a project, calls out how awesome it is. A bunch of people prove that it isn't, then the creator's response is "well, help me".
I would certainly appreciate it when stumbling over the repo.
It could also be argued that Wireguard's support for roaming clients is not much better. Roaming clients really only work properly in a model with a centralized wireguard server with a fixed ip address where the roaming clients connect to the server when they roam so the current ip address for the roaming client is updated.
ZeroTier's pretty damn cool, IMO: https://github.com/zerotier/ZeroTierOne
As a bonus, it'll route directly, instead of through an Open on server, etc.
I just wish they had an alternative to curl | bash. Something like Docker's install instructions, where you don't have to look through the install script to figure out what's going on inside sudo.
Android has an app, though I don't know whether the GUI part is open source.
So far, works great for me.
Where "written in Rust" is almost a show stopper for me because I just can't read through the source despite numerous attempts (not saying that Rust is bad of course, it's just subjectively hard to approach for me)