Hacker News Reader

Comment by thequailman | Hacker News Reader

WireGuard is actually pretty awful from an IT security org perspective. There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures. Additionally, there is no concept of two step auth, so if your key is compromised, anyone can connect without anyone knowing about the compromise.

If security companies adopt WireGuard, expect things like PulseSecure to remain as a wrapper around WireGuard. They'll at least standardize on a performant and verifiable VPN solution.

View on HN

There are (at least) two pieces to WireGuard. The wireguard "wire" protocol itself, which is implemented in the kernel. And the authentication and key exchange, that are done by userspace tools.

Right now there exist the "default" tools, which require a manual exchange of key pairs and do only very rudimentary user mapping and authorization.

However: It is perfectly possible to implement much more complex authorization schemes, with all the two step auth, logging, etc. you desire. Somebody has to write the tools for that, still. But the nice thing is, that this is a pretty much independent task, which you could do over any transport/protocol you desire (HTTPS, SSH, custom made, etc.).

An idea I've had for a longer time, but don't have the time to actually invest developing it, is using wireguard for a pure IPv6 mesh VPN.

- The ULA network part would be the key-id (lower bits) of the mesh public key (i.e. with knowledge of the mesh private key you can join the mesh), used for the mesh setup.

- The Host part would be each individual host's key-id (again lower bits of the public key).

Since wireguard uses Cryptokey Routing (https://www.wireguard.com/#cryptokey-routing) this would directly map.

If you haven't already, you should give Yggdrasil (https://github.com/yggdrasil-network/yggdrasil-go/blob/maste...) a read.

> IP addresses are derived from cryptographic keys, to reduce the need for public key infrastructure

> WireGuard is actually pretty awful from an IT security org perspective. There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures. Additionally, there is no concept of two step auth, so if your key is compromised, anyone can connect without anyone knowing about the compromise.

WireGuard's open source. Also you should bring these points up on the mailing lists. Even if you're not the one who writes it, mentioning it should put it on peoples' radar.

As you noted, Wireguard is only a part of what makes the current VPN solutions.

But that does not mean that it will stay that way. There's already effort at wg-dynamic, for dynamic allocation of ip addresses (as opposed to static allocation, which is current status quo in wireguard).

Later, it might be worth of effort to try running 802.1x over wireguard for authentication and accounting.

> There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures.

I'm wondering if this would be a use case for eBPF

See this comment here https://news.ycombinator.com/item?id=21742178

Apologies for sounding flippant: this sounds like a good opportunity for someone to build tools that use wireguard as a foundation to achieve what you want.

I tend to agree with this statement. I have been tracking WireGuard as a potential replacement for PulseSecure and it's a far ways off. We need 2FA and SAML support along with dynamic address assignment and logging before we can make the case to replace PulseSecure.

Reply on news.ycombinator.com