7 ms·

> It’s a little hard to overstate how big a deal this is. [...] Nobody trusts either codebase, or, for that matter, either crypto protocol. Both are nightmares

by jolmg 8y ago

> It’s a little hard to overstate how big a deal this is. [...] Nobody trusts either codebase, or, for that matter, either crypto protocol. Both are nightmares to configure and manage. Those seem quite the overstatements. I don't remember having any particular distrust in OpenVPN's codebase or protocol. I also didn't have that much trouble configuring neither the server nor the clients. I particularly liked how OpenVPN's configuration is basically putting command line arguments in a file. I could test configurations by simply changing invocations of openvpn, and when I found something I liked, I just put the options in a file and enabled the service to use that configuration file. Compared to the configuration of other kinds of services, OpenVPN is pretty simple. EDIT: This is my first time hearing of WireGuard. I can't say how it compares, but the way this reads like a sales pitch and is so dismissive of SSH and OpenVPN, both of which I've had nothing but good experiences from, doesn't leave a good impression on me. I mean: > Death to SSH over the public Internet. Death to OpenVPN. Death to IPSEC. Long live WireGuard! Really? This page would've been more effective on me if it objectively described how WireGuard was better than these technologies.

dewyatt 8y ago
It's just pure marketing - create a problem where it doesn't exist, and sell the solution.
- lvh 8y ago
  Would you care to rebut the arguments the blog post puts forth, such as argue that wireguard is actually harder to configure than IPSec or that the protocol is actually less trustworthy? IPsec’s design era, implementation size... really nothing about the thing is even vaguely comparable. Also: wireguard is free and open source software. So what precisely are we (people advocating for it) selling? We paid a hell of a lot more than the cost of an OpenVPN AS license so that everyone could get a macOS client, for free. I don’t make a dime off of you using wireguard. So far 100% of the deployed OpenVPN I’ve seen has had bad crypto. Wireguard just categorically doesn’t have that problem.
- atonse 8y ago
  Oh the problem definitely exists. And it shows in the fact that only more sophisticated teams use VPN. And when they have to use VPN, too many teams use OpenVPN because it's seemingly the easiest to use. Also there are scripts like the amazing Algo that make it easier to run your own VPN server. But this has historically been a totally unsolved problem from the perspective of usability. I look at it as the difference between PGP and keybase. PGP was always too complex to use, and that's a bad security design. Keybase is a lot easier to use (and Signal even easier). Wireguard is like that. Although I haven't used it yet, the configurations seem like "really? that's it? there's got to be more to it"
- seanieb 8y ago
  Stated with such confidence... Clearly you've never dug into the internals of OpenVPN.
lvh 8y ago
It does give extensive rationale: not only is it easy to configure (much easier than OpenVPN, let alone anything IPsec), the trusted codebase is tiny, and the cryptographic protocol is significantly more trustworthy. Respectfully: I suggest you check out the research and design that went into wireguard first, because he trustworthiness of the two protocols is not the same just because you’re unfamiliar with it.
nickpsecurity 8y ago
Its underlying library, OpenSSL, had all kinds of issues. OpenVPN itself allowed many configurations of varying strength and weakness. OpenVPN users could set their own security up to fail while getting false assurances because they were "using a VPN." It was also a large, complex codebase which simultaneously increases number of incidental vulnerabilities and the work necessary for defenders to prevent/find all of them. When one government adopted it, the security firm had to do a lot of hardening (OpenVPN-NL) to reduce its risks. That shouldn't be necessary in a VPN. On contrary, WireGuard started with strongest crypto it could making it default. There's also the protocol and implementation correctness to consider. WireGuard was formally-verified in Tamarin, kept small on purpose to reduce errors, carefully coded by project author focusing on security more than feature bloat, and reviewed with positive results by other security-focused coders. It's better assurance than OpenVPN across the board. Even if I didn't have those details, the fact that WireGuard is usable out of the box in Linux while OpenVPN needs to be hardened and extra-carefully configured first would already tell me what I need to know. Use WireGuard, not OpenVPN, if you're able to.
- gshulegaard 8y ago
  Just throwing it out there, but WireGuard does more than just make strong crypto "default". Instead of separating, say, transport from encryption (transformation) they tightly couple them. It's intentionally limiting this flexibility for the sake of performance and administration simplicity...in their own words: > It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. (https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf) Just skimming their whitepaper it seems this is done to cram everything into Layer 3 which has administrative and performance benefits. But comes with a significant tradeoff to flexibility. They follow up that statement with something that slightly confuses me: > As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally. But the general sense I am getting is WireGuard is strongly opinionated and limited...and one way of spinning that is less vulnerable to user error. Personally, I have trouble equating that to meaning WireGuard is more secure. For similar reasons I have trouble equating OpenVPN configuration to "requiring hardening". That said WireGuard's approach and lower layer, like IPsec, has some serious performance advantages over OpenVPN. Their whitepaper also seems to indicate that it performs better the IPsec, but I would have to see more benchmarks from other sources before making a definitive conclusion on that. Judging from this article and the comments in this overall thread though, it appears that WireGuard has some zealous (perhaps a bit over-zealous) evangelists though.
tptacek 8y ago
Here's the OpenVPN security announcements page: https://community.openvpn.net/openvpn/wiki/SecurityAnnouncements https://community.openvpn.net/openvpn/wiki/SecurityAnnouncem... There was a serverside remote code execution vulnerability in OpenVPN less than a year ago. OpenVPN is large and gnarly. It's not one of the better understood codebases. The assumption that software security assessors have closely inspected it would not be well-founded. It has had "formal" audits, but audits are point-in-time snapshots done under timebox conditions. The point of WireGuard, from an assurance perspective, is that it's designed to mitigate these concerns. It is a VPN with most of the mechanism of legacy VPNs stripped out. Less mechanism = less attack surface. It's two orders of magnitude smaller than other VPNs in terms of lines of code. Less code = easier to review = more reviews. It's not just small: it's thoughtfully small, as the post we're commenting spells out. OpenVPN is built on TLS. TLS is a complicated protocol. It needs to support a variety of different users and the complexity of that task shows in the protocol; that complexity (and legacy support) is also a big part of the vulnerability history of TLS. Ordinarily, it would be worth assuming the risks of TLS's complexity rather than building a custom transport protocol, because secure transport protocols can be tricky to get right. But WireGuard has had formal academic analysis (in addition to a Tamarin model) and inherits cryptographic design from work Trevor Perrin did. WireGuard's protocol only has to serve WireGuard's use case, and is significantly less likely to have cryptographic vulnerabilities than TLS or the OpenVPN system as a whole. The right way to think about it is that OpenVPN is like Sendmail, and WireGuard is something closer to qmail.
- bradknowles 8y ago
  Likening WireGuard to qmail is not doing them any favours. DJB abandoned the qmail codebase years ago. When he was still actively maintaining qmail, I knew of multiple cases where bugs were reported, but DJB declared them to be "non problems" and therefore he didn't have to pay out his bug bounty. And yet those "non bugs" got fixed in the next release. DJB has a history of saying one thing a certain way, but when someone else says the exact same thing in slightly different way, he declares them to have committed heresy, libel, and/or slander, and then starts talking about filing a lawsuit against them. In fact, I wouldn't be too surprised if he were to threaten you with a lawsuit over comparing his product to WireGuard. I would recommend that maybe you might want to find a better way to explain the difference.
topspin 8y ago
OpenVPN isn't that hard to configure; I have also done this on a few occasions. However, I do believe it's true to claim that to approach WireGuard's "standard" attack surface profile with OpenVPN you have to go beyond basic, naive OpenVPN configuration. Hardening OpenVPN requires additional effort and some amount of expertise and investigation to evaluate and apply configuration choices and the configuration you end up with must be aligned to by clients as well; a complication when you have limited access to or authority over the clients. I agree that the page is a bit hyperbolic but don't let that dissuade you from investigating WireGuard; the people behind WireGuard are hard headed engineers and the work is worthy of your attention.
kashyapc 8y ago
Yes, as an everyday user of OpenVPN for years, I find the above "death chants" extremely off-putting and amateurish. It implies the author of the post has little elementary common sense to resist not to foul-mouth existing projects that are serving a useful purpose. Speaking of WireGuard ... FWIW, we made a QEMU Advent Calendar[1] disk image[2] for it in 2016 December. Check that out if you want to give it a spin in a virtual machine. Reading this thread reminds me to give it a try again now. (I recall listening to the Wireguard talk at FOSDEM 2017, and a long-time Linux kernel developer, who works on memory management, was sitting next to me and remarked that he was not convinced of some details -- but unfortunately I don't remember the technical reason he mentioned as to why he thought so. Sorry :-( ) [1] http://www.qemu-advent-calendar.org/2016/#about http://www.qemu-advent-calendar.org/2016/#about [2] http://www.qemu-advent-calendar.org/2016/#day-21 http://www.qemu-advent-calendar.org/2016/#day-21
- kashyapc 8y ago
  Hm, guess the down votes are for the useless remark in brackets at the end, which I already hesitated before hitting "reply"; was genuinely trying to recall. (And probably for the chiding of the post author in the first paragraph.) Live and learn.
Panino 8y ago
> Those seem quite the overstatements. In addition to other comments, OpenVPN's default cipher is Blowfish. Since that sounds unbelievable, here's the manpage: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage "The default is BF-CBC, an abbreviation for Blowfish in Cipher Block Chaining mode." If you read just a little further you'll see that RC2, 56-bit DES and other obsolete ciphers are supported as well. To put this in perspective, DES is from the same time period as Pink Floyd's Dark Side of the Moon. I'm very excited for WireGuard to be ported to other platforms.
- aeries 8y ago
  When both sides are OpenVPN 2.4+, AES-256-GCM will be negotiated by default.
  - agnokapathetic 8y ago
    Emphasis on "negotiated". The entire negotiation and key agreement stack is a larger codebase than all of Wireguard.
    - stouset 8y ago
      The difference between “it can be made to work securely” and “it works securely” is much more important than most people realize.
zizek23 8y ago
Wireguard is easier to configure and use and in my informal tests performed at close to line speed, around 870 Mbs on a gigabit network. This is extremely fast for an encrypted network given most other solutions tend to take a severe toll on performance often operating at 140/180 Mbs on gigabit networks. The only drawback currently is it's a kernel module and needs to be compiled, which makes setup across systems a bit involved, however there are ongoing efforts to merge into the kernel. It's unfortunate innovate open source tools like Wireguard that add a lot of value to networking and clustering are not more well known.
- bradknowles 8y ago
  OpenVPN can also be configured to operate a near line speed. It all depends on the underlying hardware, software, and configuration you're using. Without being more specific in those areas and benchmarking the best reasonable configuration of one tool against the best reasonable configuration of the other tool, and then holding the rest of the factors constant, you've created a completely implausible and unsupportable conclusion. I'm not saying that WireGuard isn't faster. I'm saying that you have done a poor job of describing how it is faster, and pointing to benchmark references to back up your claims.
- bsder 8y ago
  > The only drawback currently is it's a kernel module and needs to be compiled, which makes setup across systems a bit involved, however there are ongoing efforts to merge into the kernel. Do these things have to be kernel modules? Is this a kernel module on OS X? I ask because 90%+ of the time my OS X system goes unstable the moment I add a .kext.
  - mcpherrinm 8y ago
    There is a Go implementation which runs in userspace, which is what the OSX version is. No .kext here.
lisper 8y ago
> This page would've been more effective on me if it objectively described how WireGuard was better than these technologies. Not to mention telling me where to find the code.

by jolmg 8y ago

dewyatt 8y ago

It's just pure marketing - create a problem where it doesn't exist, and sell the solution.

lvh 8y ago
Would you care to rebut the arguments the blog post puts forth, such as argue that wireguard is actually harder to configure than IPSec or that the protocol is actually less trustworthy? IPsec’s design era, implementation size... really nothing about the thing is even vaguely comparable. Also: wireguard is free and open source software. So what precisely are we (people advocating for it) selling? We paid a hell of a lot more than the cost of an OpenVPN AS license so that everyone could get a macOS client, for free. I don’t make a dime off of you using wireguard. So far 100% of the deployed OpenVPN I’ve seen has had bad crypto. Wireguard just categorically doesn’t have that problem.
atonse 8y ago
Oh the problem definitely exists. And it shows in the fact that only more sophisticated teams use VPN. And when they have to use VPN, too many teams use OpenVPN because it's seemingly the easiest to use. Also there are scripts like the amazing Algo that make it easier to run your own VPN server. But this has historically been a totally unsolved problem from the perspective of usability. I look at it as the difference between PGP and keybase. PGP was always too complex to use, and that's a bad security design. Keybase is a lot easier to use (and Signal even easier). Wireguard is like that. Although I haven't used it yet, the configurations seem like "really? that's it? there's got to be more to it"
seanieb 8y ago
Stated with such confidence... Clearly you've never dug into the internals of OpenVPN.

lvh 8y ago

It does give extensive rationale: not only is it easy to configure (much easier than OpenVPN, let alone anything IPsec), the trusted codebase is tiny, and the cryptographic protocol is significantly more trustworthy. Respectfully: I suggest you check out the research and design that went into wireguard first, because he trustworthiness of the two protocols is not the same just because you’re unfamiliar with it.

nickpsecurity 8y ago

Its underlying library, OpenSSL, had all kinds of issues. OpenVPN itself allowed many configurations of varying strength and weakness. OpenVPN users could set their own security up to fail while getting false assurances because they were "using a VPN." It was also a large, complex codebase which simultaneously increases number of incidental vulnerabilities and the work necessary for defenders to prevent/find all of them. When one government adopted it, the security firm had to do a lot of hardening (OpenVPN-NL) to reduce its risks. That shouldn't be necessary in a VPN. On contrary, WireGuard started with strongest crypto it could making it default. There's also the protocol and implementation correctness to consider. WireGuard was formally-verified in Tamarin, kept small on purpose to reduce errors, carefully coded by project author focusing on security more than feature bloat, and reviewed with positive results by other security-focused coders. It's better assurance than OpenVPN across the board. Even if I didn't have those details, the fact that WireGuard is usable out of the box in Linux while OpenVPN needs to be hardened and extra-carefully configured first would already tell me what I need to know. Use WireGuard, not OpenVPN, if you're able to.

gshulegaard 8y ago
Just throwing it out there, but WireGuard does more than just make strong crypto "default". Instead of separating, say, transport from encryption (transformation) they tightly couple them. It's intentionally limiting this flexibility for the sake of performance and administration simplicity...in their own words: > It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. (https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf) Just skimming their whitepaper it seems this is done to cram everything into Layer 3 which has administrative and performance benefits. But comes with a significant tradeoff to flexibility. They follow up that statement with something that slightly confuses me: > As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally. But the general sense I am getting is WireGuard is strongly opinionated and limited...and one way of spinning that is less vulnerable to user error. Personally, I have trouble equating that to meaning WireGuard is more secure. For similar reasons I have trouble equating OpenVPN configuration to "requiring hardening". That said WireGuard's approach and lower layer, like IPsec, has some serious performance advantages over OpenVPN. Their whitepaper also seems to indicate that it performs better the IPsec, but I would have to see more benchmarks from other sources before making a definitive conclusion on that. Judging from this article and the comments in this overall thread though, it appears that WireGuard has some zealous (perhaps a bit over-zealous) evangelists though.

tptacek 8y ago

Here's the OpenVPN security announcements page: https://community.openvpn.net/openvpn/wiki/SecurityAnnouncements https://community.openvpn.net/openvpn/wiki/SecurityAnnouncem... There was a serverside remote code execution vulnerability in OpenVPN less than a year ago. OpenVPN is large and gnarly. It's not one of the better understood codebases. The assumption that software security assessors have closely inspected it would not be well-founded. It has had "formal" audits, but audits are point-in-time snapshots done under timebox conditions. The point of WireGuard, from an assurance perspective, is that it's designed to mitigate these concerns. It is a VPN with most of the mechanism of legacy VPNs stripped out. Less mechanism = less attack surface. It's two orders of magnitude smaller than other VPNs in terms of lines of code. Less code = easier to review = more reviews. It's not just small: it's thoughtfully small, as the post we're commenting spells out. OpenVPN is built on TLS. TLS is a complicated protocol. It needs to support a variety of different users and the complexity of that task shows in the protocol; that complexity (and legacy support) is also a big part of the vulnerability history of TLS. Ordinarily, it would be worth assuming the risks of TLS's complexity rather than building a custom transport protocol, because secure transport protocols can be tricky to get right. But WireGuard has had formal academic analysis (in addition to a Tamarin model) and inherits cryptographic design from work Trevor Perrin did. WireGuard's protocol only has to serve WireGuard's use case, and is significantly less likely to have cryptographic vulnerabilities than TLS or the OpenVPN system as a whole. The right way to think about it is that OpenVPN is like Sendmail, and WireGuard is something closer to qmail.

bradknowles 8y ago
Likening WireGuard to qmail is not doing them any favours. DJB abandoned the qmail codebase years ago. When he was still actively maintaining qmail, I knew of multiple cases where bugs were reported, but DJB declared them to be "non problems" and therefore he didn't have to pay out his bug bounty. And yet those "non bugs" got fixed in the next release. DJB has a history of saying one thing a certain way, but when someone else says the exact same thing in slightly different way, he declares them to have committed heresy, libel, and/or slander, and then starts talking about filing a lawsuit against them. In fact, I wouldn't be too surprised if he were to threaten you with a lawsuit over comparing his product to WireGuard. I would recommend that maybe you might want to find a better way to explain the difference.

topspin 8y ago

OpenVPN isn't that hard to configure; I have also done this on a few occasions. However, I do believe it's true to claim that to approach WireGuard's "standard" attack surface profile with OpenVPN you have to go beyond basic, naive OpenVPN configuration. Hardening OpenVPN requires additional effort and some amount of expertise and investigation to evaluate and apply configuration choices and the configuration you end up with must be aligned to by clients as well; a complication when you have limited access to or authority over the clients. I agree that the page is a bit hyperbolic but don't let that dissuade you from investigating WireGuard; the people behind WireGuard are hard headed engineers and the work is worthy of your attention.

kashyapc 8y ago

Yes, as an everyday user of OpenVPN for years, I find the above "death chants" extremely off-putting and amateurish. It implies the author of the post has little elementary common sense to resist not to foul-mouth existing projects that are serving a useful purpose. Speaking of WireGuard ... FWIW, we made a QEMU Advent Calendar[1] disk image[2] for it in 2016 December. Check that out if you want to give it a spin in a virtual machine. Reading this thread reminds me to give it a try again now. (I recall listening to the Wireguard talk at FOSDEM 2017, and a long-time Linux kernel developer, who works on memory management, was sitting next to me and remarked that he was not convinced of some details -- but unfortunately I don't remember the technical reason he mentioned as to why he thought so. Sorry :-( ) [1] http://www.qemu-advent-calendar.org/2016/#about http://www.qemu-advent-calendar.org/2016/#about [2] http://www.qemu-advent-calendar.org/2016/#day-21 http://www.qemu-advent-calendar.org/2016/#day-21

kashyapc 8y ago
Hm, guess the down votes are for the useless remark in brackets at the end, which I already hesitated before hitting "reply"; was genuinely trying to recall. (And probably for the chiding of the post author in the first paragraph.) Live and learn.

Panino 8y ago

> Those seem quite the overstatements. In addition to other comments, OpenVPN's default cipher is Blowfish. Since that sounds unbelievable, here's the manpage: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage "The default is BF-CBC, an abbreviation for Blowfish in Cipher Block Chaining mode." If you read just a little further you'll see that RC2, 56-bit DES and other obsolete ciphers are supported as well. To put this in perspective, DES is from the same time period as Pink Floyd's Dark Side of the Moon. I'm very excited for WireGuard to be ported to other platforms.

aeries 8y ago
When both sides are OpenVPN 2.4+, AES-256-GCM will be negotiated by default.
- agnokapathetic 8y ago
  Emphasis on "negotiated". The entire negotiation and key agreement stack is a larger codebase than all of Wireguard.
  - stouset 8y ago
    The difference between “it can be made to work securely” and “it works securely” is much more important than most people realize.

zizek23 8y ago

Wireguard is easier to configure and use and in my informal tests performed at close to line speed, around 870 Mbs on a gigabit network. This is extremely fast for an encrypted network given most other solutions tend to take a severe toll on performance often operating at 140/180 Mbs on gigabit networks. The only drawback currently is it's a kernel module and needs to be compiled, which makes setup across systems a bit involved, however there are ongoing efforts to merge into the kernel. It's unfortunate innovate open source tools like Wireguard that add a lot of value to networking and clustering are not more well known.

bradknowles 8y ago
OpenVPN can also be configured to operate a near line speed. It all depends on the underlying hardware, software, and configuration you're using. Without being more specific in those areas and benchmarking the best reasonable configuration of one tool against the best reasonable configuration of the other tool, and then holding the rest of the factors constant, you've created a completely implausible and unsupportable conclusion. I'm not saying that WireGuard isn't faster. I'm saying that you have done a poor job of describing how it is faster, and pointing to benchmark references to back up your claims.
bsder 8y ago
> The only drawback currently is it's a kernel module and needs to be compiled, which makes setup across systems a bit involved, however there are ongoing efforts to merge into the kernel. Do these things have to be kernel modules? Is this a kernel module on OS X? I ask because 90%+ of the time my OS X system goes unstable the moment I add a .kext.
- mcpherrinm 8y ago
  There is a Go implementation which runs in userspace, which is what the OSX version is. No .kext here.

lisper 8y ago

> This page would've been more effective on me if it objectively described how WireGuard was better than these technologies. Not to mention telling me where to find the code.