6 ms·

The main idea (which has a fair amount of merit!) seems to be: If you give people too many knobs, they will invariably get confused and turn them the wrong way,

The main idea (which has a fair amount of merit!) seems to be: If you give people too many knobs, they will invariably get confused and turn them the wrong way, creating an insecure configuration. E.g., IPsec has a “none” cipher!

Hello71 7y ago
the "none" cipher isn't even that bad... if you do a packet capture, you can clearly see that the data is unencrypted. the worst part about IPsec is that there are many modes which look secure, but actually aren't secure at all. examples: encrypted but unauthenticated packets, encrypted but unauthenticated channel negotiation, encrypted by default but downgradable cipher negotiation...
- Avamander 7y ago
  This is why I abandoned using it, knowing the average quality of an online article I couldn't trust that the configuration was secure and there were no official very secure templates.
  - wahern 7y ago
    This is a problem with the IKE implementation. A secure IPSec configuration on OpenBSD is a single line, and you can copy+paste it from the excellent man page. Part of what makes WireGuard "simple" is that it doesn't support any kind of key management--i.e. PKI. Instead you're expected to copy keys around manually. IKE is the most complex part of the IPSec software stack but in many ways the most important part. Ironically but entirely predictably, people are using homegrown scripts and proprietary third-party services to replace the missing key management aspect of WireGuard. When these turn out to be insecure, or at least the weakest link in the chain, nobody will ever blame WireGuard, even though it will be a predictable consequence of using WireGuard.
    - Avamander 7y ago
      > on OpenBSD is a single line Nice, but it would be nice to know if that is the default or not on Linux as well. I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME. I really hated the PKI on Linux, especially when trying to revoke old keys than on Wireguard. The fact that clients also differed heavily in what they supported was also very annoying.
      - wahern 7y ago
        > Nice, but it would be nice to know if that is the default or not on Linux as well. It's because OpenBSD uses a much nicer, more declarative configuration file syntax, whereas the options on Linux, like Openswan, use a less expressive key-value syntax. To be fair, AFAIU Openswan supports more IKE extensions, and is an older project with more baggage than OpenIKEd or OpenBSD's ipsecctl configuration compiler front-end for isakmpd. But that only highlights the fact that much of the complexity of IPSec is due to history, not because IPSec is intrinsically too complex to make it useable. The SLoC of IPSec kernel code are comparable to the SLoC for WireGuard kernel code. There are smarter ways to implement IPSec and IKE, especially when you have the benefit of hindsight. > I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME It doesn't automate CA renewal, but you can't even do any kind of PKI using WireGuard as WireGuard doesn't support key signing or key authorities. FWIW, OpenBSD provides a utility for generating and manipulating X.509 certificates for use with IKE.[1] I've never used it as I'm unfortunately quite familiar with PKIX infrastructure and have my own tools, but AFAIU it's what most people use. None of this is to say that, when comparing apples to apples, WireGuard isn't a better protocol than IPSec. But SSH also has warts and it would be trivial to come up with a better replacement protocol. We don't need to because we have OpenSSH, a smart implementation that continually discards as much baggage as it can, while still interoperating with a wider ecosystem of alternative implementations. The fundamental problem is that 1) key management is hard, 2) key management is critical to overall safety and usability. WireGuard sidesteps all of this. It looks great on paper because it's only solving the easiest problem. And it seems great in practice because the ugliness of the ancillary infrastructure isn't counted against it, even though from a wholistic standpoint it should. [1] https://man.openbsd.org/ikectl.8#PKI_AND_CERTIFICATE_AUTHORITY_COMMANDS https://man.openbsd.org/ikectl.8#PKI_AND_CERTIFICATE_AUTHORI...

Hello71 7y ago

the "none" cipher isn't even that bad... if you do a packet capture, you can clearly see that the data is unencrypted. the worst part about IPsec is that there are many modes which look secure, but actually aren't secure at all. examples: encrypted but unauthenticated packets, encrypted but unauthenticated channel negotiation, encrypted by default but downgradable cipher negotiation...

Avamander 7y ago
This is why I abandoned using it, knowing the average quality of an online article I couldn't trust that the configuration was secure and there were no official very secure templates.
- wahern 7y ago
  This is a problem with the IKE implementation. A secure IPSec configuration on OpenBSD is a single line, and you can copy+paste it from the excellent man page. Part of what makes WireGuard "simple" is that it doesn't support any kind of key management--i.e. PKI. Instead you're expected to copy keys around manually. IKE is the most complex part of the IPSec software stack but in many ways the most important part. Ironically but entirely predictably, people are using homegrown scripts and proprietary third-party services to replace the missing key management aspect of WireGuard. When these turn out to be insecure, or at least the weakest link in the chain, nobody will ever blame WireGuard, even though it will be a predictable consequence of using WireGuard.
  - Avamander 7y ago
    > on OpenBSD is a single line Nice, but it would be nice to know if that is the default or not on Linux as well. I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME. I really hated the PKI on Linux, especially when trying to revoke old keys than on Wireguard. The fact that clients also differed heavily in what they supported was also very annoying.
    - wahern 7y ago
      > Nice, but it would be nice to know if that is the default or not on Linux as well. It's because OpenBSD uses a much nicer, more declarative configuration file syntax, whereas the options on Linux, like Openswan, use a less expressive key-value syntax. To be fair, AFAIU Openswan supports more IKE extensions, and is an older project with more baggage than OpenIKEd or OpenBSD's ipsecctl configuration compiler front-end for isakmpd. But that only highlights the fact that much of the complexity of IPSec is due to history, not because IPSec is intrinsically too complex to make it useable. The SLoC of IPSec kernel code are comparable to the SLoC for WireGuard kernel code. There are smarter ways to implement IPSec and IKE, especially when you have the benefit of hindsight. > I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME It doesn't automate CA renewal, but you can't even do any kind of PKI using WireGuard as WireGuard doesn't support key signing or key authorities. FWIW, OpenBSD provides a utility for generating and manipulating X.509 certificates for use with IKE.[1] I've never used it as I'm unfortunately quite familiar with PKIX infrastructure and have my own tools, but AFAIU it's what most people use. None of this is to say that, when comparing apples to apples, WireGuard isn't a better protocol than IPSec. But SSH also has warts and it would be trivial to come up with a better replacement protocol. We don't need to because we have OpenSSH, a smart implementation that continually discards as much baggage as it can, while still interoperating with a wider ecosystem of alternative implementations. The fundamental problem is that 1) key management is hard, 2) key management is critical to overall safety and usability. WireGuard sidesteps all of this. It looks great on paper because it's only solving the easiest problem. And it seems great in practice because the ugliness of the ancillary infrastructure isn't counted against it, even though from a wholistic standpoint it should. [1] https://man.openbsd.org/ikectl.8#PKI_AND_CERTIFICATE_AUTHORITY_COMMANDS https://man.openbsd.org/ikectl.8#PKI_AND_CERTIFICATE_AUTHORI...