This is why I abandoned using it, knowing the average quality of an online article I couldn't trust that the configuration was secure and there were no official very secure templates.
This is a problem with the IKE implementation. A secure IPSec configuration on OpenBSD is a single line, and you can copy+paste it from the excellent man page.
Part of what makes WireGuard "simple" is that it doesn't support any kind of key management--i.e. PKI. Instead you're expected to copy keys around manually. IKE is the most complex part of the IPSec software stack but in many ways the most important part.
Ironically but entirely predictably, people are using homegrown scripts and proprietary third-party services to replace the missing key management aspect of WireGuard. When these turn out to be insecure, or at least the weakest link in the chain, nobody will ever blame WireGuard, even though it will be a predictable consequence of using WireGuard.
Nice, but it would be nice to know if that is the default or not on Linux as well.
I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME. I really hated the PKI on Linux, especially when trying to revoke old keys than on Wireguard. The fact that clients also differed heavily in what they supported was also very annoying.
> Nice, but it would be nice to know if that is the default or not on Linux as well.
It's because OpenBSD uses a much nicer, more declarative configuration file syntax, whereas the options on Linux, like Openswan, use a less expressive key-value syntax. To be fair, AFAIU Openswan supports more IKE extensions, and is an older project with more baggage than OpenIKEd or OpenBSD's ipsecctl configuration compiler front-end for isakmpd. But that only highlights the fact that much of the complexity of IPSec is due to history, not because IPSec is intrinsically too complex to make it useable. The SLoC of IPSec kernel code are comparable to the SLoC for WireGuard kernel code. There are smarter ways to implement IPSec and IKE, especially when you have the benefit of hindsight.
> I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME
It doesn't automate CA renewal, but you can't even do any kind of PKI using WireGuard as WireGuard doesn't support key signing or key authorities.
FWIW, OpenBSD provides a utility for generating and manipulating X.509 certificates for use with IKE.[1] I've never used it as I'm unfortunately quite familiar with PKIX infrastructure and have my own tools, but AFAIU it's what most people use.
None of this is to say that, when comparing apples to apples, WireGuard isn't a better protocol than IPSec. But SSH also has warts and it would be trivial to come up with a better replacement protocol. We don't need to because we have OpenSSH, a smart implementation that continually discards as much baggage as it can, while still interoperating with a wider ecosystem of alternative implementations.
The fundamental problem is that 1) key management is hard, 2) key management is critical to overall safety and usability. WireGuard sidesteps all of this. It looks great on paper because it's only solving the easiest problem. And it seems great in practice because the ugliness of the ancillary infrastructure isn't counted against it, even though from a wholistic standpoint it should.
> The SLoC of IPSec kernel code are comparable to the SLoC for WireGuard kernel code.
I haven't checked whether this is true, but even if it is, that's a damning indictment of IPsec, because on Linux, the entire connection establishment is in userspace, and the kernel only handles per-packet encryption and authentication. WireGuard has the entire negotiation sequence, authentication, routing, timeouts, rekeying, etc in the kernel. With IPsec, you need to have a userspace daemon to manage all of that, with significantly more LoC than the bare per-packet essentials. With WireGuard, you just load the keys into the kernel and you're done. I bet that you're also counting Zinc against WireGuard, but not counting the entire crypto API against IPsec (which, unlike with WireGuard, you might end up actually using).
I suspect that it's not actually true though in the first place, once you add in all of the other stuff like iptables -m policy that only exists to support IPsec.
People say complicated PKIs are the most important parts of systems because they are complicated and hard to work with and people get invested in them and all the time they've sunk into them. But in reality, far more people have been secured by SSH keys than by IPSEC keys, and by Signal than by S/MIME.
Signal isn't an apposite comparison as Signal implements key signing and key exchange with Signal as the sole certificate authority. Who do you think attests to the authenticity of phone numbers, and how do you think they do so? Indeed, Signal exemplifies exactly what I was saying: key management is crucial, key management is hard. Secure, trusted key management is like 90% of Signal's value-add.
At large organizations SSH is often used with signed X.509 certificates. OpenSSH resisted the feature request for years, but the demand was overwhelming. The rise of products like Teleport and ScaleFT are perhaps best characterized as extremely convoluted combination key management and VPN solutions.
You say "complicated PKI", but my point is that WireGuard has no PKI. In any event PKI is intrinsically complicated. Take WireGuard and add the simplest possible trusted authority scheme on top and you've doubled the conceptual complexity by 2-3x, and possibly the SLoC, too.
Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point. The Web PKI is something we live with because we have to, not something anyone sets out to re-create.
There are organizations that benefit from a PKI-ier deployment of SSH, but even there, the "I" part of the PKI is extremely attenuated, and most of the real interesting work is done by a single centralized point of trust that mints time- and usage- limited token-equivalents. They're not trees so much as they are vines or fungus colonies. They're great, but they're certainly not a vindication of the 1990s concept of a PKI.
> Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point.
I assume then that you exchange the public keys of your Signal contacts over SMS. Over perhaps you scp them to a server you share with friends.
> The Web PKI is something we live with because we have to, not something anyone sets out to re-create.
We have to because it's crucial. If public key attestation didn't matter we would have dispensed with the lock icon and "this certificate is untrusted" popups rather than laud the emergence of Let's Encrypt and the ACME protocol.
> > Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point.
> I assume then that you exchange the public keys of your Signal contacts over SMS. Over perhaps you scp them to a server you share with friends.
You are meant to verify your contacts' keys (aka "safety numbers") either in-person or otherwise out-of-band. The Signal server does not in any way sign or endorse the identity keys they serve to users (yes, they're delivered over TLS but that doesn't count).
Yes, Signal does do some best-effort verification of your phone number when you register a device but that's just to avoid DoS. SMS can be easily intercepted.
