Decentralized VPN Written in Go(github.com)
github.com
Decentralized VPN Written in Go
https://github.com/mehrdadrad/radvpn
51 comments
But it’s written in Go and that makes all the difference!
Yes. That is why it is interesting. Want to democratic this area so no big brother. But then.
Ironically, Wireguard has an official Go implementation...
I suddenly wondered if the Go compiler would ever insert anything that phones home to Google or if any of the networking parts end up providing data to Google in any way.
Microsoft has already tried this one.
https://reddit.com/r/cpp/comments/4ibauu/
https://reddit.com/r/cpp/comments/4ibauu/
Why is Go so special that it needs to be mentioned every time there's a project using it?
"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.
"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 am far more willing to give Go projects a try due to how slim and easy they are to install (or remove) and get running, than say rails. Java is right out for me, and I absolutely refuse to run java apps on my home server unless they're dockerized, and even then I try to avoid them.
So for me at least, being written in Go is absolutely a pro.
So for me at least, being written in Go is absolutely a pro.
Security software written in a type-safe, memory-safe language is very appealing. Entire classes of vulnerabilities are removed using Go or Rust.
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.
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.
Go gets dunked on by the likes of the RESF for being "not a real systems programming language because it has GC", or "it lacks generics, therefore it's obviously unsuited for real software engineering" that actual, performant infrastructure software written in Go is indeed intriguing.
fad driven development
I believe that was sarcasm ^^;
337 times for "written in rust".
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 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 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.
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 :)
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 :)
I’ve never managed to like Python as a language, but I used to recommend it to beginners as a learning language. Mostly because you can do real things in it.
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.
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.
Given the audience here, the information may be considered interesting. For example, if I'm interested in VPN technology and want to build this, read some code or contribute to it, the language used may be a deciding factor.
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).
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).
Almost all of those are show stoppers...
Wireguard also suffers from having static routing. It could be argued that it is somewhat worse with Wireguard because there is no means for a client to announce networks for routing. I would argue that dynamic routing is a complicated task which goes far beyond just announcing networks and should be handled outside the vpn client. Wirguard's use of allowed ips and NBMA network model complicates doing so.
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.
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.
Aside from the cryptorouting concept and some convenience functions in wg-quick, Wireguard doesn't really have strong opinions on routing. It's perfectly legitimate to setup an interface with a single peer and global (0.0.0.0/0, ::/0) routes then use BGP to announce networks across it and manage the kernel route tables.
Could you open an issue detailing your concerns to give some visibility to the non-HN user?
I would certainly appreciate it when stumbling over the repo.
I would certainly appreciate it when stumbling over the repo.
> symmetrical crypto with shared key across all clients
:/
> no support for roaming clients like phones
This isn't that uncommon. I think OpenVPN might not support that either.
> or clients behind NAT
:(
:/
> no support for roaming clients like phones
This isn't that uncommon. I think OpenVPN might not support that either.
> or clients behind NAT
:(
Most of the decent, semi-mature decentralized VPN or VPN-like meshnet things I can find are GPL or LGPL, so App Store incompatible, meaning no Apple phones (or tablets), at least.
I don't use Apple, but https://play.google.com/store/apps/details?id=net.openvpn.op... works great for my phones and tablets.
All valid points. But it’s open to pull requests it being open source and all.
> - symmetrical crypto with shared key across all clients, letting any VPN client act as any other client
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.
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.
> > - 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 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.
> 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.
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.
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.
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 did not suggest a PR for security related issues but for lacking featues, which is perfectly normal.
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 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.
> a PR would be nice
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 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 am not the creator. But lacking features does not make it less awesome so long as the main purpose of the project is in a usable and stable state. Lacking features means OP did not need them so they did not implement it. You share it and if people like it and ask for features or do a PR you add it. What is wrong with that?
Is this similar to ZeroTier https://www.zerotier.com/?
Except not as battle hardened and with fewer features, but otherwise that's what it looks like to me
ZeroTier's pretty damn cool, IMO: https://github.com/zerotier/ZeroTierOne
ZeroTier's pretty damn cool, IMO: https://github.com/zerotier/ZeroTierOne
ZeroTier is cool. With it on, I can just grab a file / test something on my laptop without needing to expose it publicly and either setup dyndns or grab my laptop's assigned IP address. I can just keep one bookmark for each service.
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.
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.
Both Debian and Void Linux have proper packages; did not try other distros.
Android has an app, though I don't know whether the GUI part is open source.
So far, works great for me.
Android has an app, though I don't know whether the GUI part is open source.
So far, works great for me.
The curl | bash just figures out your distro, adds the appropriate setup to your package manager, and installs a package. You can do it all by hand if you want.
Apart from "written in X" is kind of clickbaity I find it useful after all. I think that Go code is clear and readable and so it would be much easier to add missing feature and use if I had such need.
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)
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)
With WireGuard in the kernel, and even systemd support, why? What is this even aiming to offer that wg doesn't or couldn't be better done as an abstraction over wg (e.g. if you wanted a Go library for it)?
Hijacking this for a project I created a while back. An ansible role that creates a "mesh" VPN between a set of servers using wireguard: https://github.com/mawalu/wireguard-private-networking
Related, recently on HN[0]: https://github.com/jedisct1/dsvpn
[0] https://news.ycombinator.com/item?id=20571739
[0] https://news.ycombinator.com/item?id=20571739
[deleted]
Those free vpn you can get from people who want to target you and get your traffic ? Not as bad I hope.
There is also a Rust[1] implementation.
[1] https://github.com/dswd/vpncloud
[1] https://github.com/dswd/vpncloud
ltbarcly3(3)
- 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.