There's no predefined way of setting up and sharing keypairs, for one. As a company end user logging into a VPN, what you want is a place to input your username and password (and potentially 2FA credentials), not “create a keypair and give the public key to an admin”.
It's true that the WireGuard ecosystem needs these features. But it's also true that people believe VPN software needs lots of features because other VPNs are complex; people do not generally believe these things about SSH, and WireGuard makes VPN tunnels as easy to manage as SSH.
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.
> 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.
I am mostly talking about in a business setting. WireGuard hasn't even hit its first "official release". A company is not going to switch to something that has not been thoroughly vetted. Also a lot is going to have to wait on vendor support, like incorporating WireGuard into something like Cisco AnyConnect.
CVEs mean that a company can take action to mitigate a vulnerability. Wireguard is not mature enough to have something like that. A known vulnerability is bad, but not nearly as bad as an unknown vulnerability.
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.
I don't know what this means but can't think of an interpretation that isn't false. WireGuard will certainly do a better job mitigating vulnerabilities than Cisco will, and WireGuard's code will for obvious reasons get more attention than Cisco's horrible VPN code.
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.
Will take another look at wg once keys can be stored in non-exportable way on devices, or temporary keys generated per session after passing some auth mechanism. Sounds like a fun personal project.
my point is that it would appear that "Anyconnect Secure Mobility Client" has a shitton of vulnerabilities. sure, wireguard may have some vulnerabilities, but you don't need a formal audit to tell the difference between "this might have some issues" and "holy fuck this is a fucking dumpster fire". you need an audit to tell if "this might have some issues" is "this has some issues" or "this is actually pretty good". in particular, "Anyconnect Secure Mobility Client" appears to have a significant number of local privilege escalation exploits, some several dozen since 2011. that doesn't necessarily mean that the protocol is shit, but it probably does. it probably means that no serious security professionals have examined it, and the vulnerabilities that have been found are just the easiest ones that can be found with a scanner.
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.
CVE does cover "pre-release" software, part of the argument being you can't simply label something as "beta" and escape CVE coverage especially if millions of people are using it (Google's Chrome web browser was a good example of this). For example:
Sure, but Donenfield has specifically declared that CVEs not be issued for "pre-release" Wireguard components[1]:
> 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).
Also to reiterate: "which would not be eligible for CVEs, since this is pre-release snapshot software" is not correct. It's usually correct, but not 100%.
In reality WireGuard's only valid selling point is that it's easier to use than alternatives.
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.
Those benchmarks are weird. We did a test, just for fun, comparing wireguard and IKEv2 using strongswan (using ike=aes128gcm16-prfsha256-curve25519!). Strongswan came out ever so slightly faster, but with a SHITLOAD of retries. We tried different things, but the only way we got the retires down was switching cipher to chacha20-poly1305 (which made it sliiiightly slower than wireguard). There was basically zero network latency in this test, which makes me wonder how IKEv2 would have looked over the real internet.
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).
Why?