4 ms·

Yes, agree - the original article displays such a bad understanding of security that customers should avoid taking any operational advice, security-related or n

by geofft 7y ago

Yes, agree - the original article displays such a bad understanding of security that customers should avoid taking any operational advice, security-related or not, from the person who wrote it. The author of the original article seems to be making the following assumptions: - "Secure" is only about what protocols you support, and not about the quality of implementation, whether the protocols are implemented accurately, etc. In the author's world, Heartbleed (which was introduced as part of DTLS, part of Cisco's VPN implementation) doesn't exist, the Pulse Secure vulnerability that left Travelex completely non-operational doesn't exist, etc. - That said, "3DES with MD5" is a good cryptographic protocol to use, and you should avoid fancier things like "AES-256 with SHA1." - You should only consider using black boxes from companies like Cisco and Juniper (authors of Pulse Secure). If it's not compatible with those appliances, it's not worth using. - You can't ever upgrade software in a reliable fashion. Everyone is running old, unpatched versions of software, and it's better for that unpatched software with all the well-known zero-days to connect to your corporate network than to be blocked from connecting. - You should directly connect your internal network to "third parties that you do not control," and you should let those third parties dictate your software choices instead of vice versa. In this world, you have nothing other than constant disasters. I guess it's good for job security, especially for someone whose job is professional support for IPsec. It's a shame it needed debunking, but I'm glad someone did.

Spivak 7y ago
I agree with his point about software upgrades. Everyone is running old unpatched versions of software! WireGuard just externalities the messy upgrade process that will accumulate over time when you have to support devices and services that only support specific versions of the protocol. You’ll end up having to run multiple WG instances in the “transition period” that never actually ends rather than just negotiating the most secure thing you both support. And you can still cut people off from broken algos. Having compatibility with the major vendors in the space is a real advantage because it’s a de facto standard I can get other companies and partners to agree on because they’re probably running one of those black boxes. You don’t have actually use any of them, but you will get a call down the road to interface with one of them. I think the main thing is that WireGuard is a beautiful clean protocol that is about to get buried under piles of shoddy middleware to deal with the messy real world.
- geofft 7y ago
  Then the first thing you need to do as part of setting up a VPN program is to figure out a software update process/policy that lets you push updates within hours and ensures you always do have the ability to patch (i.e., that you either know where you're getting updated binaries from for every client OS that connects or you know how to build them yourself). If you build a system where updates are part of the process, it works - take a look at say video games (which have far fewer people caring about their security than, like, the average corporate VPN), where having people on the latest version is just part of the expectations, and it works fine. Otherwise, what's your plan for a Heartbleed-style scenario? Wait months for everyone to upgrade?
  - Spivak 7y ago
    I feel like you’re assuming that I will have total control over every device that wants to connect which just isn’t realistic. I mean the baseline case of a VPN that your employees use by both their work computers, personal computers, and phones. I can’t forcibly update all of those and politically I can’t cut people off because the truth is that being able to get work done is more important to the business. Then I have to deal with vendor provided devices that are slow to receive updates or possibly will never receive updates ever. Again, I can’t just turn them off much as I would like to. No room in the budget to buy replacements. The old one is working fiiiine. And then I have to deal with partners and oh boy I can’t even pretend to understand why they’re using an out of warranty Cisco box from 5 years ago but we make too much money through them to raise a fuss. So that’s what I got. Everything I own gets migrated immediately. The help desk goes after everyone who doesn’t know how to update their apps. And we make special exceptions for random junk that can’t ever upgrade but is too valuable to turn off. So yeah, you pretty much have to wait months for the stragglers but everyone who can upgrade does so immediately. I’m sure lots of people here can tell lots of horror stories about turning off TLS 1.1.
    - geofft 7y ago
      > I mean the baseline case of a VPN that your employees use by both their work computers, personal computers, and phones. I can’t forcibly update all of those and politically I can’t cut people off because the truth is that being able to get work done is more important to the business. Then your priority isn't security. Which isn't necessarily a criticism, it's just a statement of what your business's priorities are. Don't hide behind "well, IPsec supports all sorts of security knobs that can make it approximately as good as Wireguard, if you squint hard enough this is actually the more secure thing." Just say, no, security is not the top priority for this application, and we're going to design our systems around connectivity/reliability instead of security. You could decide security goes elsewhere the design, if you want, and add additional internal isolation once someone's on the VPN to avoid infected endpoints from messing with your corporate network. You could also just decide that a VPN isn't what you want, you want cloud services and BeyondCorp and the assumption of mostly-untrusted endpoints. (Then your users don't have to install VPN software at all, they just need a web browser.) Or for your partners with the out-of-warranty Cisco box - stick a firewall in front of them on your side and also arrange to use authenticated/encrypted application protocols as if you were connecting over the public network. Or say, security and reliability are both priorities but cost isn't, we're buying everyone a work-managed laptop and a work-managed phone. (Or, if you really want to connect from your personal device, you can use a fully-patched one, and if you don't have one, the company will buy you one. Or whatever.) But you cannot say that your priority is security and your priority is allowing unpatched devices to connect. (I don't know anyone with a horror story about turning off TLS 1.1 who originally turned it on because they wanted secure connections. All of those people supported TLS 1.2 and the good ciphers before anyone forced them to. I know people with horror stories because they turned on TLS because they needed to check some regulator's checkbox.)
Spooky23 7y ago
I agree the original article was really dumb, and sounded like it was written by an enterprise network guy who has only worked with and been trained by big vendors. That said, the fatal flaw of Wireguard is the crypto model. Nobody who interacts with the US government, regulated US industries, or some F500 will be able to use it because of the fixed algorithm choice, which isn’t possibly FIPS 140-2 validatable. You’ll always need that Cisco/Pulse/whatever box. That may be a feature for some, but it kneecaps the possibility of it being as ubiquitous as it might be otherwise.
- microcolonel 7y ago
  I mean, we can just update the legislation to accept the competent ciphersuites, or the government can publish that once-in-a-century whitepaper where they demonstrate that DJB has been a brilliant CIA shill this whole time and the nothing-up-my-sleeve numbers have something up their sleeves. Like, I get that that is not likely to happen, but the resistance of the state to competence is not an excuse for resistance to it outside the state.
- tptacek 7y ago
  It's a trap, because your options boil down to: (a) Using FIPS cryptography, which is inferior, to placate the USG. (b) Using best-practices cryptography, and being incompatible with some places that mandate FIPS. (c) Supporting both FIPS and non-FIPS cryptography, which creates handshake bugs and gives you lowest-common-denominator security. I think you can reasonable argue that (a) and (b) are both superior to (c); I think WireGuard made the right choice here. In the long run, for enterprise environments, I don't think this much matters. Even with FIPS cryptography, stodgy enterprises won't adopt WireGuard until it becomes so prevalent elsewhere that they have to, simply because IPSEC has more standardization. So the WireGuard task is simply to make it so prevalent everywhere else that stodgy enterprises no long have a vote.

by geofft 7y ago

Spivak 7y ago

I agree with his point about software upgrades. Everyone is running old unpatched versions of software! WireGuard just externalities the messy upgrade process that will accumulate over time when you have to support devices and services that only support specific versions of the protocol. You’ll end up having to run multiple WG instances in the “transition period” that never actually ends rather than just negotiating the most secure thing you both support. And you can still cut people off from broken algos. Having compatibility with the major vendors in the space is a real advantage because it’s a de facto standard I can get other companies and partners to agree on because they’re probably running one of those black boxes. You don’t have actually use any of them, but you will get a call down the road to interface with one of them. I think the main thing is that WireGuard is a beautiful clean protocol that is about to get buried under piles of shoddy middleware to deal with the messy real world.

geofft 7y ago
Then the first thing you need to do as part of setting up a VPN program is to figure out a software update process/policy that lets you push updates within hours and ensures you always do have the ability to patch (i.e., that you either know where you're getting updated binaries from for every client OS that connects or you know how to build them yourself). If you build a system where updates are part of the process, it works - take a look at say video games (which have far fewer people caring about their security than, like, the average corporate VPN), where having people on the latest version is just part of the expectations, and it works fine. Otherwise, what's your plan for a Heartbleed-style scenario? Wait months for everyone to upgrade?
- Spivak 7y ago
  I feel like you’re assuming that I will have total control over every device that wants to connect which just isn’t realistic. I mean the baseline case of a VPN that your employees use by both their work computers, personal computers, and phones. I can’t forcibly update all of those and politically I can’t cut people off because the truth is that being able to get work done is more important to the business. Then I have to deal with vendor provided devices that are slow to receive updates or possibly will never receive updates ever. Again, I can’t just turn them off much as I would like to. No room in the budget to buy replacements. The old one is working fiiiine. And then I have to deal with partners and oh boy I can’t even pretend to understand why they’re using an out of warranty Cisco box from 5 years ago but we make too much money through them to raise a fuss. So that’s what I got. Everything I own gets migrated immediately. The help desk goes after everyone who doesn’t know how to update their apps. And we make special exceptions for random junk that can’t ever upgrade but is too valuable to turn off. So yeah, you pretty much have to wait months for the stragglers but everyone who can upgrade does so immediately. I’m sure lots of people here can tell lots of horror stories about turning off TLS 1.1.
  - geofft 7y ago
    > I mean the baseline case of a VPN that your employees use by both their work computers, personal computers, and phones. I can’t forcibly update all of those and politically I can’t cut people off because the truth is that being able to get work done is more important to the business. Then your priority isn't security. Which isn't necessarily a criticism, it's just a statement of what your business's priorities are. Don't hide behind "well, IPsec supports all sorts of security knobs that can make it approximately as good as Wireguard, if you squint hard enough this is actually the more secure thing." Just say, no, security is not the top priority for this application, and we're going to design our systems around connectivity/reliability instead of security. You could decide security goes elsewhere the design, if you want, and add additional internal isolation once someone's on the VPN to avoid infected endpoints from messing with your corporate network. You could also just decide that a VPN isn't what you want, you want cloud services and BeyondCorp and the assumption of mostly-untrusted endpoints. (Then your users don't have to install VPN software at all, they just need a web browser.) Or for your partners with the out-of-warranty Cisco box - stick a firewall in front of them on your side and also arrange to use authenticated/encrypted application protocols as if you were connecting over the public network. Or say, security and reliability are both priorities but cost isn't, we're buying everyone a work-managed laptop and a work-managed phone. (Or, if you really want to connect from your personal device, you can use a fully-patched one, and if you don't have one, the company will buy you one. Or whatever.) But you cannot say that your priority is security and your priority is allowing unpatched devices to connect. (I don't know anyone with a horror story about turning off TLS 1.1 who originally turned it on because they wanted secure connections. All of those people supported TLS 1.2 and the good ciphers before anyone forced them to. I know people with horror stories because they turned on TLS because they needed to check some regulator's checkbox.)

Spooky23 7y ago

I agree the original article was really dumb, and sounded like it was written by an enterprise network guy who has only worked with and been trained by big vendors. That said, the fatal flaw of Wireguard is the crypto model. Nobody who interacts with the US government, regulated US industries, or some F500 will be able to use it because of the fixed algorithm choice, which isn’t possibly FIPS 140-2 validatable. You’ll always need that Cisco/Pulse/whatever box. That may be a feature for some, but it kneecaps the possibility of it being as ubiquitous as it might be otherwise.

microcolonel 7y ago
I mean, we can just update the legislation to accept the competent ciphersuites, or the government can publish that once-in-a-century whitepaper where they demonstrate that DJB has been a brilliant CIA shill this whole time and the nothing-up-my-sleeve numbers have something up their sleeves. Like, I get that that is not likely to happen, but the resistance of the state to competence is not an excuse for resistance to it outside the state.
tptacek 7y ago
It's a trap, because your options boil down to: (a) Using FIPS cryptography, which is inferior, to placate the USG. (b) Using best-practices cryptography, and being incompatible with some places that mandate FIPS. (c) Supporting both FIPS and non-FIPS cryptography, which creates handshake bugs and gives you lowest-common-denominator security. I think you can reasonable argue that (a) and (b) are both superior to (c); I think WireGuard made the right choice here. In the long run, for enterprise environments, I don't think this much matters. Even with FIPS cryptography, stodgy enterprises won't adopt WireGuard until it becomes so prevalent elsewhere that they have to, simply because IPSEC has more standardization. So the WireGuard task is simply to make it so prevalent everywhere else that stodgy enterprises no long have a vote.