> While I don't believe WireGuard is a drop in replacement for IPsec tunnels or OpenVPN
Why?
Why?
Another thing people might not realize if they haven't had to deal with lots of different VPN configurations is that most of the "user management" and "2FA" features of legacy VPNs are, as the kids say, janky "AF".
Ultimately, organizations should be tying their VPNs, like everything else, into an IdP of some sort, and most of the "user management" and "MFA" stuff belongs to the IdP, not the VPN. People will clearly get WireGuard integrated into Okta.
Right, but at the moment this integration does not exist.
You'd be best without a username a password, just a code.
doesn't seem very secure to me.
This is not a knock on Wireguard, I use wireguard and love it. It just has several hoops to jump through before it is ready for widespread adoption. Like NIST approving it to be used instead of IPsec or OpenVPN.
It's true that Fortune 500 companies aren't going to deploy WireGuard. They're constitutionally incapable of deploying security gear that isn't awful, which is why a huge fraction of all VPN deployments through the F500 were backdoored in the 2000s.
NIST is never going to approve WireGuard; it's not even a discussion worth having, nor is it NIST's place to certify which VPNs are or aren't safe to use, nor does NIST have the staff to do anything like that.
That's no reason for startup engineers to make the same mistake. Startups definitely do deploy WireGuard.
but even ignoring all of that, wireguard has significantly better security guarantees. https://www.wireguard.com/formal-verification/ claims that "WireGuard has undergone all sorts of formal verification, covering aspects of the cryptography, protocol, and implementation." with references to several formal proofs of the protocol.
furthermore, wireguard has actually received a CVE: CVE-2019-14899, which was posted here only a few weeks ago. it's not wireguard-specific though, it's a general problem with VPN setup on general-purpose operating systems.
With this exception, WireGuard does not CVEs because it is (for now) still considered pre-release software and not recommended for production use.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prereleases
> Current snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software).
CVE is just an identifier for a security vulnerability.
"Common Vulnerabilities and Exposures"
CVE generally covers released software, hardware and (in the process or being added officially) services. It also covers beta software (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=beta).
The reason Wireguard doesn't have CVEs is nobody has bothered to request them.
For more details on CVE there's a bunch of episodes covering it: https://www.opensourcesecuritypodcast.com/search?q=cve
It is not, for example, faster than the literally dozens of ASIC implementations of bump in the wire IPsec that scale to line rate n * 100Gbps. It's not even faster than kernel IPsec on architectures which support AES with dedicated instructions. Incidentally, this is the default configuration for Strongswan on supporting hardware.
In fact, the benchmarks published prominently on the WireGuard website (https://www.wireguard.com/performance/) are completely nonsensical and compare the clients under circumstances where neither should be bottlenecked and where it is known the underlying algorithm with AES-NI is considerably faster than chacha20-poly1305. Yet, they find that WireGuard achieves higher throughput (magically exceeding line rate, in fact!) in spite of more header overhead and a slower algorithm. They find WireGuard is lower latency by something like an order of magnitude more than the actual single packet latency for an IPsec compression with AES-NI. When I find the official hard data about a product to be complete bullshit, it raises a lot of red flags for me. Either the authors of this marketing fluff are completely ignorant or completely dishonest, but in neither case does the material motivate interest in the product.
It's extremely debatable that it's more secure than common IPsec implementations. The core IPsec implementation is a very simple state machine which has been under review by virtually everyone with an interest in secure comms for decades. It's very wishful to suggest that some hipster shitware that got puked out a few years ago because Strongswan was too hard is "more secure".
If you're in the position of designing a secure interconnect for something more consequential than a friend accessing your home media server and do not have the luxury of abdicating responsibility for the outcome, the fact that the client is easy to use is perhaps the single lowest bullet point on your list of priorities. Interoperability with existing software and hardware, flexibility to adapt to different customer environments and requirements, maturity and proven performance all rate much more highly. IPsec is and has been the go-to for that, while WireGuard is drenched in hype and bullshit and completely unproven.
As you said: I am not a network admin, so I probably botched something. Which, I guess, is another point for wireguard in my book. It lacks many of the bells and whistles of IPsec, which means less to configure for the average stupid home user (me).