7 ms·

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 tr

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?

fivesixzero 7y ago
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.
GekkePrutser 7y ago
Smaller codebase means less chance of bugs. But I agree, it should really be audited properly before this statement can be made.
- cyphar 7y ago
  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]. [1]: https://www.wireguard.com/formal-verification/ https://www.wireguard.com/formal-verification/ [2]: https://www.youtube.com/watch?v=CejbCQ5wS7Q https://www.youtube.com/watch?v=CejbCQ5wS7Q (about 23 minutes in)
dsr_ 7y ago
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.
Sesse__ 7y ago
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. E.g., IPsec has a “none” cipher!
- Hello71 7y ago
  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...
  - Avamander 7y ago
    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.
    - wahern 7y ago
      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.
      - Avamander 7y ago
        > on OpenBSD is a single line 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.
vsareto 7y ago
That's not really a weak claim: https://stackoverflow.com/a/56043694 https://stackoverflow.com/a/56043694 (citations in Code Complete)
tptacek 7y ago
* 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".
qzx_pierri 7y ago
The article says the smaller codebase doesn’t make Wireguard more secure, but it only makes it easier to audit.

fivesixzero 7y ago

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.

GekkePrutser 7y ago

Smaller codebase means less chance of bugs. But I agree, it should really be audited properly before this statement can be made.

cyphar 7y ago
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]. [1]: https://www.wireguard.com/formal-verification/ https://www.wireguard.com/formal-verification/ [2]: https://www.youtube.com/watch?v=CejbCQ5wS7Q https://www.youtube.com/watch?v=CejbCQ5wS7Q (about 23 minutes in)

dsr_ 7y ago

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.

Sesse__ 7y ago

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. E.g., IPsec has a “none” cipher!

Hello71 7y ago
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...
- Avamander 7y ago
  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.
  - wahern 7y ago
    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.
    - Avamander 7y ago
      > on OpenBSD is a single line 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.

vsareto 7y ago

That's not really a weak claim: https://stackoverflow.com/a/56043694 https://stackoverflow.com/a/56043694 (citations in Code Complete)

tptacek 7y ago

* 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".

qzx_pierri 7y ago

The article says the smaller codebase doesn’t make Wireguard more secure, but it only makes it easier to audit.