What makes Wireguard more secure? The article appears to make some weak claims about a smaller codebase and less configuration options but I don't think that translate directly into it being more secure?
* It uses a single set of well-trusted modern primitives and so avoids the attack surface of negotiation.
* Those primitives are used for a Noise construction, and Noise is itself reasonably well studied and increasingly formalized; we can be somewhat confident WireGuard is skipping over the 2 generations of protocol vulnerabilities SSL/TLS faced.
* Perhaps most importantly, the codebase is tiny and designed to minimize its attack surface; for instance, the protocol itself is designed to be implementable without dynamic memory allocation.
* WireGuard is itself minimal and doesn't implement higher-level features like user management, which means that those features aren't coupled and entangled into the core engine, and can be implemented straightforwardly through a clear interface.
In general, and contra this article, "smaller codebase" usually does mean "more secure".
The main idea (which has a fair amount of merit!) seems to be: If you give people too many knobs, they will invariably get confused and turn them the wrong way, creating an insecure configuration.
the "none" cipher isn't even that bad... if you do a packet capture, you can clearly see that the data is unencrypted. the worst part about IPsec is that there are many modes which look secure, but actually aren't secure at all. examples: encrypted but unauthenticated packets, encrypted but unauthenticated channel negotiation, encrypted by default but downgradable cipher negotiation...
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.
The main argument in the article (and other places I’ve seen WG discussed) is the relative ease of auditing the core code as well as auditing implementations. In that context it’s less of an augment that it’s “more secure” and more of an argument that it’s “more cost/time effective to assure that it (the core code or Any implementation) is secure”.
That argument can be strong when considering that effective security in most projects comes down to whether assurance of security can be discerned effectively within a limited time window. Often very limited.
Those help it be more secure without being a proof of security.
Fewer configuration options/smaller codebase mean you have less to screw up while programming, less to read while debugging, and fewer opportunities to get things wrong while deploying.
WireGuard has been extensively audited many times for the past 4-5 years, including several formal proofs[1]. I would argue no other VPN has been as thoroughly audited (not to mention that the codebase size means that an entire-codebase audit is actually possible). That doesn't mean it's perfect (and it has had bugs), but it's definitely exceptionally well designed and written code.
In addition, the crypto design (beyond it being opinionated and thus no way to misconfigure into using the "null cipher") is arguably much more secure by design than other systems. For instance, WireGuard eliminates entire classes of vulnerabilities through careful protocol design while also adding fairly neat features (such as being impossible to port scan) -- the author explains this much more eloquently than I can[2].
