6 ms·

> While I don't believe WireGuard is a drop in replacement for IPsec tunnels or OpenVPN Why?

sbradford26 7y ago
I am mostly talking about in a business setting. WireGuard hasn't even hit its first "official release". A company is not going to switch to something that has not been thoroughly vetted. Also a lot is going to have to wait on vendor support, like incorporating WireGuard into something like Cisco AnyConnect.
- Hello71 7y ago
  this cisco anyconnect system? https://www.cvedetails.com/vulnerability-list/vendor_id-16/product_id-20904/Cisco-Anyconnect-Secure-Mobility-Client.html https://www.cvedetails.com/vulnerability-list/vendor_id-16/p... doesn't seem very secure to me.
  - sbradford26 7y ago
    CVEs mean that a company can take action to mitigate a vulnerability. Wireguard is not mature enough to have something like that. A known vulnerability is bad, but not nearly as bad as an unknown vulnerability. This is not a knock on Wireguard, I use wireguard and love it. It just has several hoops to jump through before it is ready for widespread adoption. Like NIST approving it to be used instead of IPsec or OpenVPN.
    - tptacek 7y ago
      I don't know what this means but can't think of an interpretation that isn't false. WireGuard will certainly do a better job mitigating vulnerabilities than Cisco will, and WireGuard's code will for obvious reasons get more attention than Cisco's horrible VPN code. It's true that Fortune 500 companies aren't going to deploy WireGuard. They're constitutionally incapable of deploying security gear that isn't awful, which is why a huge fraction of all VPN deployments through the F500 were backdoored in the 2000s. NIST is never going to approve WireGuard; it's not even a discussion worth having, nor is it NIST's place to certify which VPNs are or aren't safe to use, nor does NIST have the staff to do anything like that. That's no reason for startup engineers to make the same mistake. Startups definitely do deploy WireGuard.
      - Hikikomori 7y ago
        Will take another look at wg once keys can be stored in non-exportable way on devices, or temporary keys generated per session after passing some auth mechanism. Sounds like a fun personal project.
    - Hello71 7y ago
      my point is that it would appear that "Anyconnect Secure Mobility Client" has a shitton of vulnerabilities. sure, wireguard may have some vulnerabilities, but you don't need a formal audit to tell the difference between "this might have some issues" and "holy fuck this is a fucking dumpster fire". you need an audit to tell if "this might have some issues" is "this has some issues" or "this is actually pretty good". in particular, "Anyconnect Secure Mobility Client" appears to have a significant number of local privilege escalation exploits, some several dozen since 2011. that doesn't necessarily mean that the protocol is shit, but it probably does. it probably means that no serious security professionals have examined it, and the vulnerabilities that have been found are just the easiest ones that can be found with a scanner. but even ignoring all of that, wireguard has significantly better security guarantees. https://www.wireguard.com/formal-verification/ https://www.wireguard.com/formal-verification/ claims that "WireGuard has undergone all sorts of formal verification, covering aspects of the cryptography, protocol, and implementation." with references to several formal proofs of the protocol. furthermore, wireguard has actually received a CVE: CVE-2019-14899, which was posted here only a few weeks ago. it's not wireguard-specific though, it's a general problem with VPN setup on general-purpose operating systems.
      - jlgaddis 7y ago
        I'm sure you know this but, for the benefit of others... With this exception, WireGuard does not CVEs because it is (for now) still considered pre-release software and not recommended for production use.
        kseifried 7y ago
        CVE does cover "pre-release" software, part of the argument being you can't simply label something as "beta" and escape CVE coverage especially if millions of people are using it (Google's Chrome web browser was a good example of this). For example: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prereleases https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prereleases
        loeg 7y ago
    - kseifried 7y ago
      Sorry but... no. You are wrong. Completely wrong. CVE is just an identifier for a security vulnerability. "Common Vulnerabilities and Exposures" CVE generally covers released software, hardware and (in the process or being added officially) services. It also covers beta software (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=beta https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=beta). The reason Wireguard doesn't have CVEs is nobody has bothered to request them. For more details on CVE there's a bunch of episodes covering it: https://www.opensourcesecuritypodcast.com/search?q=cve https://www.opensourcesecuritypodcast.com/search?q=cve
Sesse__ 7y ago
There's no predefined way of setting up and sharing keypairs, for one. As a company end user logging into a VPN, what you want is a place to input your username and password (and potentially 2FA credentials), not “create a keypair and give the public key to an admin”.
- tptacek 7y ago
  It's true that the WireGuard ecosystem needs these features. But it's also true that people believe VPN software needs lots of features because other VPNs are complex; people do not generally believe these things about SSH, and WireGuard makes VPN tunnels as easy to manage as SSH. Another thing people might not realize if they haven't had to deal with lots of different VPN configurations is that most of the "user management" and "2FA" features of legacy VPNs are, as the kids say, janky "AF". Ultimately, organizations should be tying their VPNs, like everything else, into an IdP of some sort, and most of the "user management" and "MFA" stuff belongs to the IdP, not the VPN. People will clearly get WireGuard integrated into Okta.
  - rcxdude 7y ago
    > Ultimately, organizations should be tying their VPNs, like everything else, into an IdP of some sort, and most of the "user management" and "MFA" stuff belongs to the IdP, not the VPN. People will clearly get WireGuard integrated into Okta. Right, but at the moment this integration does not exist.
    - tptacek 7y ago
      I'm not disputing that.
- zhte415 7y ago
  > what you want is a place to input your username and password You'd be best without a username a password, just a code.
1_person 7y ago
In reality WireGuard's only valid selling point is that it's easier to use than alternatives. It is not, for example, faster than the literally dozens of ASIC implementations of bump in the wire IPsec that scale to line rate n * 100Gbps. It's not even faster than kernel IPsec on architectures which support AES with dedicated instructions. Incidentally, this is the default configuration for Strongswan on supporting hardware. In fact, the benchmarks published prominently on the WireGuard website (https://www.wireguard.com/performance/ https://www.wireguard.com/performance/) are completely nonsensical and compare the clients under circumstances where neither should be bottlenecked and where it is known the underlying algorithm with AES-NI is considerably faster than chacha20-poly1305. Yet, they find that WireGuard achieves higher throughput (magically exceeding line rate, in fact!) in spite of more header overhead and a slower algorithm. They find WireGuard is lower latency by something like an order of magnitude more than the actual single packet latency for an IPsec compression with AES-NI. When I find the official hard data about a product to be complete bullshit, it raises a lot of red flags for me. Either the authors of this marketing fluff are completely ignorant or completely dishonest, but in neither case does the material motivate interest in the product. It's extremely debatable that it's more secure than common IPsec implementations. The core IPsec implementation is a very simple state machine which has been under review by virtually everyone with an interest in secure comms for decades. It's very wishful to suggest that some hipster shitware that got puked out a few years ago because Strongswan was too hard is "more secure". If you're in the position of designing a secure interconnect for something more consequential than a friend accessing your home media server and do not have the luxury of abdicating responsibility for the outcome, the fact that the client is easy to use is perhaps the single lowest bullet point on your list of priorities. Interoperability with existing software and hardware, flexibility to adapt to different customer environments and requirements, maturity and proven performance all rate much more highly. IPsec is and has been the go-to for that, while WireGuard is drenched in hype and bullshit and completely unproven.
- bjoli 7y ago
  Those benchmarks are weird. We did a test, just for fun, comparing wireguard and IKEv2 using strongswan (using ike=aes128gcm16-prfsha256-curve25519!). Strongswan came out ever so slightly faster, but with a SHITLOAD of retries. We tried different things, but the only way we got the retires down was switching cipher to chacha20-poly1305 (which made it sliiiightly slower than wireguard). There was basically zero network latency in this test, which makes me wonder how IKEv2 would have looked over the real internet. As you said: I am not a network admin, so I probably botched something. Which, I guess, is another point for wireguard in my book. It lacks many of the bells and whistles of IPsec, which means less to configure for the average stupid home user (me).

I am mostly talking about in a business setting. WireGuard hasn't even hit its first "official release". A company is not going to switch to something that has not been thoroughly vetted. Also a lot is going to have to wait on vendor support, like incorporating WireGuard into something like Cisco AnyConnect.

Hello71 7y ago
this cisco anyconnect system? https://www.cvedetails.com/vulnerability-list/vendor_id-16/product_id-20904/Cisco-Anyconnect-Secure-Mobility-Client.html https://www.cvedetails.com/vulnerability-list/vendor_id-16/p... doesn't seem very secure to me.
- sbradford26 7y ago
  CVEs mean that a company can take action to mitigate a vulnerability. Wireguard is not mature enough to have something like that. A known vulnerability is bad, but not nearly as bad as an unknown vulnerability. This is not a knock on Wireguard, I use wireguard and love it. It just has several hoops to jump through before it is ready for widespread adoption. Like NIST approving it to be used instead of IPsec or OpenVPN.
  - tptacek 7y ago
    I don't know what this means but can't think of an interpretation that isn't false. WireGuard will certainly do a better job mitigating vulnerabilities than Cisco will, and WireGuard's code will for obvious reasons get more attention than Cisco's horrible VPN code. It's true that Fortune 500 companies aren't going to deploy WireGuard. They're constitutionally incapable of deploying security gear that isn't awful, which is why a huge fraction of all VPN deployments through the F500 were backdoored in the 2000s. NIST is never going to approve WireGuard; it's not even a discussion worth having, nor is it NIST's place to certify which VPNs are or aren't safe to use, nor does NIST have the staff to do anything like that. That's no reason for startup engineers to make the same mistake. Startups definitely do deploy WireGuard.
    - Hikikomori 7y ago
      Will take another look at wg once keys can be stored in non-exportable way on devices, or temporary keys generated per session after passing some auth mechanism. Sounds like a fun personal project.
  - Hello71 7y ago
    my point is that it would appear that "Anyconnect Secure Mobility Client" has a shitton of vulnerabilities. sure, wireguard may have some vulnerabilities, but you don't need a formal audit to tell the difference between "this might have some issues" and "holy fuck this is a fucking dumpster fire". you need an audit to tell if "this might have some issues" is "this has some issues" or "this is actually pretty good". in particular, "Anyconnect Secure Mobility Client" appears to have a significant number of local privilege escalation exploits, some several dozen since 2011. that doesn't necessarily mean that the protocol is shit, but it probably does. it probably means that no serious security professionals have examined it, and the vulnerabilities that have been found are just the easiest ones that can be found with a scanner. but even ignoring all of that, wireguard has significantly better security guarantees. https://www.wireguard.com/formal-verification/ https://www.wireguard.com/formal-verification/ claims that "WireGuard has undergone all sorts of formal verification, covering aspects of the cryptography, protocol, and implementation." with references to several formal proofs of the protocol. furthermore, wireguard has actually received a CVE: CVE-2019-14899, which was posted here only a few weeks ago. it's not wireguard-specific though, it's a general problem with VPN setup on general-purpose operating systems.
    - jlgaddis 7y ago
      I'm sure you know this but, for the benefit of others... With this exception, WireGuard does not CVEs because it is (for now) still considered pre-release software and not recommended for production use.
      - kseifried 7y ago
        CVE does cover "pre-release" software, part of the argument being you can't simply label something as "beta" and escape CVE coverage especially if millions of people are using it (Google's Chrome web browser was a good example of this). For example: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prereleases https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prereleases
        loeg 7y ago
  - kseifried 7y ago
    Sorry but... no. You are wrong. Completely wrong. CVE is just an identifier for a security vulnerability. "Common Vulnerabilities and Exposures" CVE generally covers released software, hardware and (in the process or being added officially) services. It also covers beta software (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=beta https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=beta). The reason Wireguard doesn't have CVEs is nobody has bothered to request them. For more details on CVE there's a bunch of episodes covering it: https://www.opensourcesecuritypodcast.com/search?q=cve https://www.opensourcesecuritypodcast.com/search?q=cve

Sesse__ 7y ago

There's no predefined way of setting up and sharing keypairs, for one. As a company end user logging into a VPN, what you want is a place to input your username and password (and potentially 2FA credentials), not “create a keypair and give the public key to an admin”.

tptacek 7y ago
It's true that the WireGuard ecosystem needs these features. But it's also true that people believe VPN software needs lots of features because other VPNs are complex; people do not generally believe these things about SSH, and WireGuard makes VPN tunnels as easy to manage as SSH. Another thing people might not realize if they haven't had to deal with lots of different VPN configurations is that most of the "user management" and "2FA" features of legacy VPNs are, as the kids say, janky "AF". Ultimately, organizations should be tying their VPNs, like everything else, into an IdP of some sort, and most of the "user management" and "MFA" stuff belongs to the IdP, not the VPN. People will clearly get WireGuard integrated into Okta.
- rcxdude 7y ago
  > Ultimately, organizations should be tying their VPNs, like everything else, into an IdP of some sort, and most of the "user management" and "MFA" stuff belongs to the IdP, not the VPN. People will clearly get WireGuard integrated into Okta. Right, but at the moment this integration does not exist.
  - tptacek 7y ago
    I'm not disputing that.
zhte415 7y ago
> what you want is a place to input your username and password You'd be best without a username a password, just a code.

1_person 7y ago

In reality WireGuard's only valid selling point is that it's easier to use than alternatives. It is not, for example, faster than the literally dozens of ASIC implementations of bump in the wire IPsec that scale to line rate n * 100Gbps. It's not even faster than kernel IPsec on architectures which support AES with dedicated instructions. Incidentally, this is the default configuration for Strongswan on supporting hardware. In fact, the benchmarks published prominently on the WireGuard website (https://www.wireguard.com/performance/ https://www.wireguard.com/performance/) are completely nonsensical and compare the clients under circumstances where neither should be bottlenecked and where it is known the underlying algorithm with AES-NI is considerably faster than chacha20-poly1305. Yet, they find that WireGuard achieves higher throughput (magically exceeding line rate, in fact!) in spite of more header overhead and a slower algorithm. They find WireGuard is lower latency by something like an order of magnitude more than the actual single packet latency for an IPsec compression with AES-NI. When I find the official hard data about a product to be complete bullshit, it raises a lot of red flags for me. Either the authors of this marketing fluff are completely ignorant or completely dishonest, but in neither case does the material motivate interest in the product. It's extremely debatable that it's more secure than common IPsec implementations. The core IPsec implementation is a very simple state machine which has been under review by virtually everyone with an interest in secure comms for decades. It's very wishful to suggest that some hipster shitware that got puked out a few years ago because Strongswan was too hard is "more secure". If you're in the position of designing a secure interconnect for something more consequential than a friend accessing your home media server and do not have the luxury of abdicating responsibility for the outcome, the fact that the client is easy to use is perhaps the single lowest bullet point on your list of priorities. Interoperability with existing software and hardware, flexibility to adapt to different customer environments and requirements, maturity and proven performance all rate much more highly. IPsec is and has been the go-to for that, while WireGuard is drenched in hype and bullshit and completely unproven.

bjoli 7y ago
Those benchmarks are weird. We did a test, just for fun, comparing wireguard and IKEv2 using strongswan (using ike=aes128gcm16-prfsha256-curve25519!). Strongswan came out ever so slightly faster, but with a SHITLOAD of retries. We tried different things, but the only way we got the retires down was switching cipher to chacha20-poly1305 (which made it sliiiightly slower than wireguard). There was basically zero network latency in this test, which makes me wonder how IKEv2 would have looked over the real internet. As you said: I am not a network admin, so I probably botched something. Which, I guess, is another point for wireguard in my book. It lacks many of the bells and whistles of IPsec, which means less to configure for the average stupid home user (me).