Earlier quoted context omitted.
> It very explicitly doesn't want to deal with integrating with key management/HSMs/AD policies/whatever. If you look at the list of vulnerabilities, they're all precisely in those parts of the stack that Wireguard doesn't address. So what value is Wireguard providing, exactly? It's a beautiful protocol, but security isn't a beauty contest. It's easy to create a beautiful solution when you avoid dealing with the diff…
> If you look at the list of vulnerabilities If you look at THIS list of vulnerabilities, sure. That's not an exhaustive list of every problem standard VPNs have had though, you understand that right? > So what value is Wireguard providing, exactly? Even ignoring vulnerabilities entirely, OpenVPN and the like are full of footguns and are very, very easy to fuck yourself with. You talk about the value of practicality…
But the value those SSL-based and similar bespoke VPN servers brought was automated key management, end-user based authentication, route setup, etc. They've done so horribly in terms of correctness and security, but nonetheless in a way that companies value.
Yes, Wireguard avoids all the pitfalls of the transport security. But so do the crappy SSL-based solutions, because they also have the benefit of hindsight.
What's the practical value of Wireguard over IPSec? AFAICT, it has marginally better NAT traversal; IPSec requires NAT-T (a UDP wrapper) which is marginally more complex. But what's the biggest impediment to IPSec uptake? It's IKE, which is a purely userland service. Most IKE implementations suck. Whatever solutions will be built around Wireguard, they'll ultimately look almost exactly like IKE in terms of their relationship to the in-kernel component--a userland daemon for PKI and/or general user authentication management which does some setup like installing the secret transport key and policy of the otherwise simple in-kernel components. But if those better IKE solutions don't exist (outside of OpenBSD), why would Wireguard magically make them appear?
At best what we'll get (what we are getting, as manifest in every VPN service and open source project announcement) with Wireguard is a recapitulation of the mess we have with SSL VPN products. All the same security issues revolving around horrible key management and poorly written software, all the same incompatibilities and vendor lock in stemming from the diverse "solutions". Except we'll have a beautiful transport layer protocol to soothe ourselves with.
I don't mean to criticize Wireguard. From a low-level engineering perspective it's beyond reproach. My concern is with how it's being received and the fantasies people have about how it will change things. And IMO (which I admit is my opinion--not a hill I'd choose to die on, but something I'd still wager on and orient my plans around) is that long-term security would be better spent by fixing (mostly deprecating old modes) and reinforcing IPSec and IKE, which is already very mature. macOS, iPhone, and Windows have mature IKEv2 support. Linux, and Android in particular, does not have mature IKEv2 support, at least not out-of-the-box. Implementations like FreeS/WAN are too complex and have too many pitfalls, which is why startups either avoid it or flounder in their attempts to build on it. If I could order open source engineers around, I'd order them to improve IKEv2 support. Why? Because IKEv2 addresses in a reasonable fashion 80% of the things that compromise the value-add of commercial VPN products. That last 20% still leaves maneuvering room for novel key and user management solutions, but without as great a risk of really f'ing things up.