7 ms·

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

by q3k 7y ago

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.

pinewurst 7y ago
But it’s written in Go and that makes all the difference!
- ngcc_hk 7y ago
  Yes. That is why it is interesting. Want to democratic this area so no big brother. But then.
- tgsovlerkhgsel 7y ago
  Ironically, Wireguard has an official Go implementation...
- fouc 7y ago
  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.
  - throwaway8941 7y ago
    Microsoft has already tried this one. https://reddit.com/r/cpp/comments/4ibauu/ https://reddit.com/r/cpp/comments/4ibauu/
- laurent123456 7y ago
  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.
  - kuroguro 7y ago
    I believe that was sarcasm ^^;
  - bborud 7y ago
    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.
    - asdkhadsj 7y ago
      > 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 :)
77pt77 7y ago
Almost all of those are show stoppers...
paulddraper 7y ago
> 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 :(
- shantly 7y ago
  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.
  - paulddraper 7y ago
    I don't use Apple, but https://play.google.com/store/apps/details?id=net.openvpn.openvpn https://play.google.com/store/apps/details?id=net.openvpn.op... works great for my phones and tablets.
gigatexal 7y ago
All valid points. But it’s open to pull requests it being open source and all.
badrabbit 7y ago
> - 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.
- DuskStar 7y ago
  > > - 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.
- tptacek 7y ago
  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.
tssva 7y ago
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.
- mcrute 7y ago
  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.
the_duke 7y ago
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.

by q3k 7y ago

pinewurst 7y ago

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

ngcc_hk 7y ago
Yes. That is why it is interesting. Want to democratic this area so no big brother. But then.
tgsovlerkhgsel 7y ago
Ironically, Wireguard has an official Go implementation...
fouc 7y ago
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.
- throwaway8941 7y ago
  Microsoft has already tried this one. https://reddit.com/r/cpp/comments/4ibauu/ https://reddit.com/r/cpp/comments/4ibauu/
laurent123456 7y ago
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.
- kuroguro 7y ago
  I believe that was sarcasm ^^;
- bborud 7y ago
  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.
  - asdkhadsj 7y ago
    > 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 :)

77pt77 7y ago

Almost all of those are show stoppers...

paulddraper 7y ago

> 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 :(

shantly 7y ago
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.
- paulddraper 7y ago
  I don't use Apple, but https://play.google.com/store/apps/details?id=net.openvpn.openvpn https://play.google.com/store/apps/details?id=net.openvpn.op... works great for my phones and tablets.

gigatexal 7y ago

All valid points. But it’s open to pull requests it being open source and all.

badrabbit 7y ago

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

DuskStar 7y ago
> > - 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.
tptacek 7y ago
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.

tssva 7y ago

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.

mcrute 7y ago
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.

the_duke 7y ago

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.