Hacker News Reader

Comment by q3k | Hacker News Reader

Looking at it for a few minutes, this has some issues:

- 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.

View on HN

But it’s written in Go and that makes all the difference!

Ironically, Wireguard has an official Go implementation...

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.

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.

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.

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.

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).

I believe that was sarcasm ^^;

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.

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

Yes. That is why it is interesting. Want to democratic this area so no big brother. But then.

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/

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.

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.

> 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

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.

> > - 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.

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.

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.

> 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 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?

Reply on news.ycombinator.com