4 ms·

Hi! Thanks for the question. It's an important one. Both the security of WireGuard as a protocol as well as its Linux kernel implementation are most likely supe

by kfreds 7y ago

Hi! Thanks for the question. It's an important one. Both the security of WireGuard as a protocol as well as its Linux kernel implementation are most likely superior to all alternatives. Code audits and age of the project function as signals for decision makers, but there are stronger signals, if you look deeper. The simplicity of the protocol state machine, the fact that it can be implemented without dynamic memory allocation, the cryptographic primitives used, and the lines of code required, are arguably equally or more useful. WireGuard is 4000 LOC, IPSec is 400,000 LOC and OpenVPN is of similar complexity. I don't expect Jason Donenfeld who has a background in kernel exploit development to write code that contains 100x more vulnerabilities than IPSec and OpenVPN. We have noted the prevalence of those arguments. Let's wait a while and see who was right. As for the privacy issues with a "standard" WireGuard deployment we are well aware of them and are working with others to develop a standard which will hopefully be adopted by privacy-focused operators. Unfortunately we only highlighted them to others in January this year. Note that no criticism of WireGuard's privacy seems to be older than this email: https://lists.zx2c4.com/pipermail/wireguard/2019-January/003777.html https://lists.zx2c4.com/pipermail/wireguard/2019-January/003... We have deployed solutions for some of WireGuard's privacy issues while others are in the pipeline. It should however be noted that some of the attack vectors are somewhat esoteric and quite unlikely, so we don't consider them critical. The devil is in the details, as you can read in my email above. On the whole we think WireGuard is where the industry should be heading, fast, for many reasons, and that's why we are spearheading it: https://mullvad.net/en/blog/2017/9/27/wireguard-future/ https://mullvad.net/en/blog/2017/9/27/wireguard-future/ At the moment IVPN is slightly ahead of us in terms of privacy features in WireGuard, but they are the provider we probably have most in common with, and we frequently discuss projects like this one, so they are definitely the one we most expect competition and collaboration from: https://www.ivpn.net/knowledgebase/253/Using-WireGuard-for-Privacy-Protection.html https://www.ivpn.net/knowledgebase/253/Using-WireGuard-for-P...

labawi 7y ago
While wireguard is probably safer and easier to setup, it has its own idiosyncrasies. Jason is stubborn enough to push through on creating a vpn, but also stubborn enough to see things his own way. I'm still wary of using it, not sure what will become of it. It has idiosyncrasies like: * Jason refuses to implement or see point of binding to an ip/address. I do not know of a serious network service that cannot bind. I guess roaming to any interface is always the right thing to do and sharing a port number for separate services on separate ips should be done via NAT. * If you assign an ip/route to a peer, that is already assigned to another peer, previous assignment is simply removed. Somehow, this is a feature and not a blunder >95% of the time. On a security product, it's better to keep going and load a kind of obviously wrong config, discarding conflicting assignments, than to raise an error. Or even a warning (a warning is/was planned). * on Windows Jason invented tying network id to hash of entire key+address configuration. Cool idea, but I guess you're supposed to fiddle with firewall settings each time you change any peer key/ip, because it's now a new network. * wireguard is marketed as a modern secure VPN. It has proofs and what not, but I haven't seen a specification of what are it's security guarantees. It (obviously) leaks packet size and timing, also ecn bits, maybe server time? Does it leak public keys, dscp markings? I guess you're supposed to read the whitepaper, maybe source code and keep an eye for any changes.
wahern 7y ago
> WireGuard is 4000 LOC, IPSec is 400,000 LOC and OpenVPN is of similar complexity. Bollocks. $ cat netinet/ip_ah.c netinet/ip_ecn.c \ netinet/ip_esp.c netinet/ip_ipsp.c netinet/ip_spd.c \ netinet/ipsec_input.c netinet/ipsec_output.c | wc -l 6445 You're comparing apples and oranges. Most critics implicitly count IKE and other PKI-related bits as part of IPSec. But Wireguard doesn't offer anything comparable. So if you want to compare apples & apples, you can only compare the actual transport layer. Wireguard is still more elegant, but of course Wireguard has the benefit of hindsight and IPSec has 20+ years of operational fixes. What's happening is that because Wireguard doesn't include PKI people end up gluing together poor man's PKI with shell scripts and shoe strings. PKI is the hard part of key management, and because Wireguard doesn't attempt to solve it, it doesn't incur any of those costs. And the people who do try to solve it and get it horrible wrong, well I guess that's just not Wireguard's fault, right? How convenient.

by kfreds 7y ago

labawi 7y ago

While wireguard is probably safer and easier to setup, it has its own idiosyncrasies. Jason is stubborn enough to push through on creating a vpn, but also stubborn enough to see things his own way. I'm still wary of using it, not sure what will become of it. It has idiosyncrasies like: * Jason refuses to implement or see point of binding to an ip/address. I do not know of a serious network service that cannot bind. I guess roaming to any interface is always the right thing to do and sharing a port number for separate services on separate ips should be done via NAT. * If you assign an ip/route to a peer, that is already assigned to another peer, previous assignment is simply removed. Somehow, this is a feature and not a blunder >95% of the time. On a security product, it's better to keep going and load a kind of obviously wrong config, discarding conflicting assignments, than to raise an error. Or even a warning (a warning is/was planned). * on Windows Jason invented tying network id to hash of entire key+address configuration. Cool idea, but I guess you're supposed to fiddle with firewall settings each time you change any peer key/ip, because it's now a new network. * wireguard is marketed as a modern secure VPN. It has proofs and what not, but I haven't seen a specification of what are it's security guarantees. It (obviously) leaks packet size and timing, also ecn bits, maybe server time? Does it leak public keys, dscp markings? I guess you're supposed to read the whitepaper, maybe source code and keep an eye for any changes.

wahern 7y ago

> WireGuard is 4000 LOC, IPSec is 400,000 LOC and OpenVPN is of similar complexity. Bollocks. $ cat netinet/ip_ah.c netinet/ip_ecn.c \ netinet/ip_esp.c netinet/ip_ipsp.c netinet/ip_spd.c \ netinet/ipsec_input.c netinet/ipsec_output.c | wc -l 6445 You're comparing apples and oranges. Most critics implicitly count IKE and other PKI-related bits as part of IPSec. But Wireguard doesn't offer anything comparable. So if you want to compare apples & apples, you can only compare the actual transport layer. Wireguard is still more elegant, but of course Wireguard has the benefit of hindsight and IPSec has 20+ years of operational fixes. What's happening is that because Wireguard doesn't include PKI people end up gluing together poor man's PKI with shell scripts and shoe strings. PKI is the hard part of key management, and because Wireguard doesn't attempt to solve it, it doesn't incur any of those costs. And the people who do try to solve it and get it horrible wrong, well I guess that's just not Wireguard's fault, right? How convenient.