5 ms·

>The gold standard, as ever, is Wireguard. Not disagreeing with you about the state of commercial VPN products, but regarding WG specifically. Something I don'

by xoa 7y ago

>The gold standard, as ever, is Wireguard. Not disagreeing with you about the state of commercial VPN products, but regarding WG specifically. Something I don't see in the other replies just yet is that Wireguard doesn't yet have an ecosystem around it, but is designed for that in a good way. By which I mean, it follows the Unix philosophy of focusing on one specific task and doing it very well, and it has succeeded in that admirably even at its early stage of development. And long term I think that will result in better, more secure and more reliable solutions. But in the immediate term solutions/ecosystems around it don't exist and I think that makes for legitimate scalability problems for anyone who doesn't want to roll their own infrastructure. It very explicitly doesn't want to deal with integrating with key management/HSMs/AD policies/whatever. Eventually WG itself will be used along with those, and there will be nice GUIs on it, and so on. Hopefully it'll simply become the standard for VPN products to rely upon and the world will be a better place for it. But in these early days it can't slot in everywhere because it's not even meant to. That'll take more time, maybe kernel mainlining (maybe after the WG port to the crypto API Jason announced last week?) and integration with the *BSDs. It's still in a fairly significant growth phase.

wahern 7y ago
> It very explicitly doesn't want to deal with integrating with key management/HSMs/AD policies/whatever. If you look at the list of vulnerabilities, they're all precisely in those parts of the stack that Wireguard doesn't address. So what value is Wireguard providing, exactly? It's a beautiful protocol, but security isn't a beauty contest. It's easy to create a beautiful solution when you avoid dealing with the difficult problems.
- xoa 7y ago
  >If you look at the list of vulnerabilities If you look at THIS list of vulnerabilities, sure. That's not an exhaustive list of every problem standard VPNs have had though, you understand that right? >So what value is Wireguard providing, exactly? Even ignoring vulnerabilities entirely, OpenVPN and the like are full of footguns and are very, very easy to fuck yourself with. You talk about the value of practicality and solutions, which is very true, and that's just the point. One of the core aspects of modern security practice is making it hard to fuck up, the few knobs and dials the better. For example, older protocols still have obsolete awful crypto options that you shouldn't use, but precisely because they exist as choices at all you have to worry about misconfiguration or classes of issues like downgrade attacks. There are plenty more, like if you remember back during Logjam, tons of SSH/VPN/HTTPS servers were using identical prime numbers for Diffie-Hellman key exchange. WG aims to be a better foundation for the VPN component of things. Contrary to your assertion, the problem it deals with isn't trivial and does matter. Having something that is focused on that rather then part of a gigantic blob makes it easier to verify, and also makes whatever auth and other systems it's ultimately tied into easier to verify. Also just plain lower overhead. I mean, I'm barely touching on things here but there are good reasons a lot of people are enthusiastic about its potential.
  - wahern 7y ago
    I'm not defending SSL-based VPN servers. They exist because people didn't understand how IPSec IKE worked or want to put in the effort to make it work better, and as is typical in the industry worse-is-better won the day. But the value those SSL-based and similar bespoke VPN servers brought was automated key management, end-user based authentication, route setup, etc. They've done so horribly in terms of correctness and security, but nonetheless in a way that companies value. Yes, Wireguard avoids all the pitfalls of the transport security. But so do the crappy SSL-based solutions, because they also have the benefit of hindsight. What's the practical value of Wireguard over IPSec? AFAICT, it has marginally better NAT traversal; IPSec requires NAT-T (a UDP wrapper) which is marginally more complex. But what's the biggest impediment to IPSec uptake? It's IKE, which is a purely userland service. Most IKE implementations suck. Whatever solutions will be built around Wireguard, they'll ultimately look almost exactly like IKE in terms of their relationship to the in-kernel component--a userland daemon for PKI and/or general user authentication management which does some setup like installing the secret transport key and policy of the otherwise simple in-kernel components. But if those better IKE solutions don't exist (outside of OpenBSD), why would Wireguard magically make them appear? At best what we'll get (what we are getting, as manifest in every VPN service and open source project announcement) with Wireguard is a recapitulation of the mess we have with SSL VPN products. All the same security issues revolving around horrible key management and poorly written software, all the same incompatibilities and vendor lock in stemming from the diverse "solutions". Except we'll have a beautiful transport layer protocol to soothe ourselves with. I don't mean to criticize Wireguard. From a low-level engineering perspective it's beyond reproach. My concern is with how it's being received and the fantasies people have about how it will change things. And IMO (which I admit is my opinion--not a hill I'd choose to die on, but something I'd still wager on and orient my plans around) is that long-term security would be better spent by fixing (mostly deprecating old modes) and reinforcing IPSec and IKE, which is already very mature. macOS, iPhone, and Windows have mature IKEv2 support. Linux, and Android in particular, does not have mature IKEv2 support, at least not out-of-the-box. Implementations like FreeS/WAN are too complex and have too many pitfalls, which is why startups either avoid it or flounder in their attempts to build on it. If I could order open source engineers around, I'd order them to improve IKEv2 support. Why? Because IKEv2 addresses in a reasonable fashion 80% of the things that compromise the value-add of commercial VPN products. That last 20% still leaves maneuvering room for novel key and user management solutions, but without as great a risk of really f'ing things up.
tptacek 7y ago
It depends on what you're using a VPN to accomplish. If you're talking about rolling out an enterprise-wide solution that does site-to-site and small branch offices and remote access, I agree: WireGuard isn't there yet (an enterprising security engineer might get it there!). But most of the VPNs I encounter in my work are not that; rather, they're simple remote access mechanisms, addressing the same problem an SSH tunnel would, but more cleanly. WireGuard is better than the alternatives for these common-case simple remote access VPNs. Additionally, there are lots of random tasks that you might want to deploy a simple point-to-point VPN to solve (peering, cross-account cloud access, etc) that OpenVPN and strongSwan are just too painful to set up. WireGuard is approximately as easy to set up as an SSH tunnel; the tunnel wants you to map ports, and WireGuard wants IP addresses. I imagine it might see a lot of deployments that legacy VPN protocols won't.
- ohazi 7y ago
  If all of my remote access can be done via ssh {+ local/remote forwarding}, is there a reason for me to consider wireguard?
  - tptacek 7y ago
    Yes. WireGuard is cryptographically superior to SSH, attaches at a network layer without fussy interactions with a Unix shell (that then also needs to be accounted for in a security model), has higher performance, is practically bulletproof in terms of keeping connections alive, and gets you direct access to whatever resources you've provisioned the network to provide. I wouldn't ding someone using SSH tunnels (carefully), but in a de novo design, I would always recommend WireGuard first.
    - labawi 7y ago
      > WireGuard .. is practically bulletproof in terms of keeping connections alive Try switching between IPv4 and IPv6 networks, or reaching a peer on non-default/primary network on Windows. Not denying it would usually have better connectivity than TCP based ssh.
petre 7y ago
Last I checked it did not have a a Windows client, so I'm still using OpenVPN. CLI clients are of course next to useless for Windows users. I would really like to use WG instead.
- tjoff 7y ago
  It does now, and it has a much better UX than OpenVPN.
- gsich 7y ago
  Tunsafe is there since quite a while. Some client from WG directly is also in the works.

by xoa 7y ago

wahern 7y ago

> It very explicitly doesn't want to deal with integrating with key management/HSMs/AD policies/whatever. If you look at the list of vulnerabilities, they're all precisely in those parts of the stack that Wireguard doesn't address. So what value is Wireguard providing, exactly? It's a beautiful protocol, but security isn't a beauty contest. It's easy to create a beautiful solution when you avoid dealing with the difficult problems.

xoa 7y ago
>If you look at the list of vulnerabilities If you look at THIS list of vulnerabilities, sure. That's not an exhaustive list of every problem standard VPNs have had though, you understand that right? >So what value is Wireguard providing, exactly? Even ignoring vulnerabilities entirely, OpenVPN and the like are full of footguns and are very, very easy to fuck yourself with. You talk about the value of practicality and solutions, which is very true, and that's just the point. One of the core aspects of modern security practice is making it hard to fuck up, the few knobs and dials the better. For example, older protocols still have obsolete awful crypto options that you shouldn't use, but precisely because they exist as choices at all you have to worry about misconfiguration or classes of issues like downgrade attacks. There are plenty more, like if you remember back during Logjam, tons of SSH/VPN/HTTPS servers were using identical prime numbers for Diffie-Hellman key exchange. WG aims to be a better foundation for the VPN component of things. Contrary to your assertion, the problem it deals with isn't trivial and does matter. Having something that is focused on that rather then part of a gigantic blob makes it easier to verify, and also makes whatever auth and other systems it's ultimately tied into easier to verify. Also just plain lower overhead. I mean, I'm barely touching on things here but there are good reasons a lot of people are enthusiastic about its potential.
- wahern 7y ago
  I'm not defending SSL-based VPN servers. They exist because people didn't understand how IPSec IKE worked or want to put in the effort to make it work better, and as is typical in the industry worse-is-better won the day. But the value those SSL-based and similar bespoke VPN servers brought was automated key management, end-user based authentication, route setup, etc. They've done so horribly in terms of correctness and security, but nonetheless in a way that companies value. Yes, Wireguard avoids all the pitfalls of the transport security. But so do the crappy SSL-based solutions, because they also have the benefit of hindsight. What's the practical value of Wireguard over IPSec? AFAICT, it has marginally better NAT traversal; IPSec requires NAT-T (a UDP wrapper) which is marginally more complex. But what's the biggest impediment to IPSec uptake? It's IKE, which is a purely userland service. Most IKE implementations suck. Whatever solutions will be built around Wireguard, they'll ultimately look almost exactly like IKE in terms of their relationship to the in-kernel component--a userland daemon for PKI and/or general user authentication management which does some setup like installing the secret transport key and policy of the otherwise simple in-kernel components. But if those better IKE solutions don't exist (outside of OpenBSD), why would Wireguard magically make them appear? At best what we'll get (what we are getting, as manifest in every VPN service and open source project announcement) with Wireguard is a recapitulation of the mess we have with SSL VPN products. All the same security issues revolving around horrible key management and poorly written software, all the same incompatibilities and vendor lock in stemming from the diverse "solutions". Except we'll have a beautiful transport layer protocol to soothe ourselves with. I don't mean to criticize Wireguard. From a low-level engineering perspective it's beyond reproach. My concern is with how it's being received and the fantasies people have about how it will change things. And IMO (which I admit is my opinion--not a hill I'd choose to die on, but something I'd still wager on and orient my plans around) is that long-term security would be better spent by fixing (mostly deprecating old modes) and reinforcing IPSec and IKE, which is already very mature. macOS, iPhone, and Windows have mature IKEv2 support. Linux, and Android in particular, does not have mature IKEv2 support, at least not out-of-the-box. Implementations like FreeS/WAN are too complex and have too many pitfalls, which is why startups either avoid it or flounder in their attempts to build on it. If I could order open source engineers around, I'd order them to improve IKEv2 support. Why? Because IKEv2 addresses in a reasonable fashion 80% of the things that compromise the value-add of commercial VPN products. That last 20% still leaves maneuvering room for novel key and user management solutions, but without as great a risk of really f'ing things up.

tptacek 7y ago

It depends on what you're using a VPN to accomplish. If you're talking about rolling out an enterprise-wide solution that does site-to-site and small branch offices and remote access, I agree: WireGuard isn't there yet (an enterprising security engineer might get it there!). But most of the VPNs I encounter in my work are not that; rather, they're simple remote access mechanisms, addressing the same problem an SSH tunnel would, but more cleanly. WireGuard is better than the alternatives for these common-case simple remote access VPNs. Additionally, there are lots of random tasks that you might want to deploy a simple point-to-point VPN to solve (peering, cross-account cloud access, etc) that OpenVPN and strongSwan are just too painful to set up. WireGuard is approximately as easy to set up as an SSH tunnel; the tunnel wants you to map ports, and WireGuard wants IP addresses. I imagine it might see a lot of deployments that legacy VPN protocols won't.

ohazi 7y ago
If all of my remote access can be done via ssh {+ local/remote forwarding}, is there a reason for me to consider wireguard?
- tptacek 7y ago
  Yes. WireGuard is cryptographically superior to SSH, attaches at a network layer without fussy interactions with a Unix shell (that then also needs to be accounted for in a security model), has higher performance, is practically bulletproof in terms of keeping connections alive, and gets you direct access to whatever resources you've provisioned the network to provide. I wouldn't ding someone using SSH tunnels (carefully), but in a de novo design, I would always recommend WireGuard first.
  - labawi 7y ago
    > WireGuard .. is practically bulletproof in terms of keeping connections alive Try switching between IPv4 and IPv6 networks, or reaching a peer on non-default/primary network on Windows. Not denying it would usually have better connectivity than TCP based ssh.

petre 7y ago

Last I checked it did not have a a Windows client, so I'm still using OpenVPN. CLI clients are of course next to useless for Windows users. I would really like to use WG instead.

tjoff 7y ago
It does now, and it has a much better UX than OpenVPN.
gsich 7y ago
Tunsafe is there since quite a while. Some client from WG directly is also in the works.