4 ms·

Intigued as to why you think it's overstated. It seems pretty robust to me. Those quotes are fairly snipey and there's quite a bit of history behind the people

by _joel 6y ago

Intigued as to why you think it's overstated. It seems pretty robust to me. Those quotes are fairly snipey and there's quite a bit of history behind the people to bias their opinion.

cmeacham98 6y ago
The website includes actual analysis on OpenBSD security as well. OpenBSD has this reputation of having some god-like security where it's leaps and bounds above every other OS. I believe its security is actually relatively similar to alternative OSs like linux, and perhaps even less as containerization seems to be getting really popular on linux right now which allows linux to somewhat catch up to what I consider to be one of the biggest advantages OpenBSD had (pledge). Most of the advocacy I see about OpenBSD security seems to be misleading and/or vague. OpenBSD's own website[1] proudly claims that OpenBSD has had "Only two remote holes in the default install, in a heck of a long time!". What is "a heck of a long time", and where's the info about any vulnerabilities other than an RCE in the default installation? 1: https://www.openbsd.org/ https://www.openbsd.org/
- nimish 6y ago
  The "trick" is the default install bit. OpenBSD's default install is very limited. Since there's basically nothing enabled, the surface is limited. They still pop up every few years or so.
- asclepi 6y ago
  IIRC, "a heck of a long time" refers to the time elapsed since the initial release of OpenBSD in July 1996. Patches for vulnerabilities are listed per release on https://www.openbsd.org/errata.html https://www.openbsd.org/errata.html
- tialaramex 6y ago
  One example that is in my wheelhouse was illustrative of the not-always-clever attitude of OpenBSD to security. If you need certificates from the Web PKI (for your SMTP server, or your IRC server, or any other TLS server, but most obviously your web server) you likely want to talk ACME to Let's Encrypt or another CA. The popular way to do this is Certbot, a program written in Python. Clearly that's a lot of dependencies and thus potential attack surface area so not ideal. A popular alternative is acme.sh which is Unix shell code. So this is potentially a far smaller attack surface but shell is hardly the most auditable or secure language by default... OpenBSD ships acme-client which is written in C. Now, acme-client uses lots of OpenBSD flavour tooling to improve on its security, components of acme-client are sandboxed off from themselves and the rest of the system using pledge() and so on such that components with access to your private keys are not also doing TCP/IP. On the surface then although it's written in an unsafe language this looks like a good trade and it exactly fits OpenBSD's approach. However, the thing about ACME is it's built out of existing standard components such as Certificate Signing Requests. So instead of attack surface in Python, or Bash, or C, and trying to mitigate it with local sandboxing, you can choose to hand the CSRs to a completely separate system and so to literally airgap your private keys and all the TLS server code from your ACME implementation if you want. You can use CSRs with Certbot, you can use CSRs with acme.sh, but, they aren't an option with OpenBSD's acme-client at all. acme-client is the Beast so that a US President can be driven somewhere very dangerous and most likely get out of there alive - but just using CSRs is having him just make a video call and never leave the safety of the Oval Office.
  - wahern 6y ago
    > However, the thing about ACME is it's built out of existing standard components such as Certificate Signing Requests. So instead of attack surface in Python, or Bash, or C, and trying to mitigate it with local sandboxing, you can choose to hand the CSRs to a completely separate system and so to literally airgap your private keys and all the TLS server code from your ACME implementation if you want. > You can use CSRs with Certbot, you can use CSRs with acme.sh, but, they aren't an option with OpenBSD's acme-client at all. acme-client uses a privilege separated process model (using pledge and unveil) so that private keys are never loaded or accessible to the network-facing process. And it's not just acme-client that does this. Most OpenBSD service daemons, like httpd and smtpd, perform private key operations in a privilege-separated subprocess. The technique won't win any awards for request throughput, but it reflects OpenBSD's "secure by default" ethos, which of course always has to be understood in the context of what they're trying to accomplish. Air-gapping the long-term account private keys for a semi-automated Let's Encrypt renewal process sounds more aspirational than anything. If you're going to attempt that, the lack of support in acme-client is the least of your problems in terms of initial and long-term operational complexity.[1] OpenBSD tools are primarily designed for the needs of OpenBSD maintainers, and secondarily for the needs of typical OpenBSD users. These people aren't trying to build the next AWS using OpenBSD, nor are they trying to secure Apple's or the NSA's proprietary key escrow system root of trust key. "Secure by default" has to be understood in that context. And so the fact other tools support more features, some of which can be used to theoretically implement hypothetically more secure systems is sort of beside the point. Moreover, a general rule of thumb is complexity is anathema to security, and OpenBSD is rigorous about providing the fewest knobs possible while minimizing administrative burden and effective risk for their typical user base. This is why the utility and pervasive use of pledge and unveil are simply incomparable to the Linux equivalents, seccomp and filesystem namespaces; and why the fact that OpenBSD services privilege separate private key operations is something most OpenBSD users, let alone non-OpenBSD, don't even realize. I don't really care about the exploit writers' opinions of OpenBSD. How many of them host and use their own public-facing web or e-mail servers? Attackers and defenders have completely different perspectives that sometimes lead to completely different opinions. And I definitely don't care about the consensus opinion of the security community considering that over the past decade the majority of self-described and even employed "security engineers" are neither experienced systems programmers nor experienced system administrators. Prowess with nmap and Wireshark seem to make for "hacker" credentials in this community. The depth and sophistication of their knowledge is about the same as many Node.js-cum-Rust programmers who write "parsers" and "servers" by stitching together a bunch of crates. That's not nothing, but I'm not going to attach much worth to their opinions regarding complex architectural or algorithmic problems. How many Kubernetes engineers can even understand the value of, let alone conceptualize or even implement, a pipelined series of network daemons that rigorously preserves backpressure? Why would I value their opinion on how to efficiently scale services when their measure of scalability and survivability is the ease with which you can throw more hardware or AWS account credits at a problem, and generate more Prometheus data sets? People who use OpenBSD over the long term know perfectly well what "secure by default" means, even when they themselves might have made different choices. [1] Not that I think air gapping is generally impossible or impractical. I've defended DNSSEC on multiple occasions for preserving this ability. And I do a lot of work with HSM, secure enclave, and smartcard integration, so I very much agree with and promote the idea of moving private key operations entirely off network-facing hosts, whether air-gapped or not. But WebPKI infrastructure tends to be operationally quite shallow and quite dynamic, making manually administered key signing operations less practical at any scale. But if someone can make it work, more power to them. In general this use case is too niche for OpenBSD to emphasize--either not enough potential utility, or invites too much complexity. The exception would be OpenSSH's recent embrace of FIDO HID USB keys, but it's not really an exception considering typical interactive ssh workflows, and considering the implementation complexity relative to the traditional ecosystem involving PKCS#11, PC/SC, PIV, etc. I don't think those latter standards are deal killers, but I totally understand and appreciate why they wouldn't see much attention from OpenBSD developers. OpenBSD continues to embrace and enhance IPSec and IKE despite the complexity, even as they integrate Wireguard; they're capable of making context-sensitive analyses.
- tachion 6y ago
  You need to be aware that while pledge is a security technology, linux containers aren't. Pledge was designed as another security layer, while containers were designed as "management" or "separation" layer, but not strictly as security measure - read up on how bad is to run things as a root in a container.

by _joel 6y ago

Intigued as to why you think it's overstated. It seems pretty robust to me. Those quotes are fairly snipey and there's quite a bit of history behind the people to bias their opinion.

cmeacham98 6y ago

The website includes actual analysis on OpenBSD security as well. OpenBSD has this reputation of having some god-like security where it's leaps and bounds above every other OS. I believe its security is actually relatively similar to alternative OSs like linux, and perhaps even less as containerization seems to be getting really popular on linux right now which allows linux to somewhat catch up to what I consider to be one of the biggest advantages OpenBSD had (pledge). Most of the advocacy I see about OpenBSD security seems to be misleading and/or vague. OpenBSD's own website[1] proudly claims that OpenBSD has had "Only two remote holes in the default install, in a heck of a long time!". What is "a heck of a long time", and where's the info about any vulnerabilities other than an RCE in the default installation? 1: https://www.openbsd.org/ https://www.openbsd.org/

nimish 6y ago
The "trick" is the default install bit. OpenBSD's default install is very limited. Since there's basically nothing enabled, the surface is limited. They still pop up every few years or so.
asclepi 6y ago
IIRC, "a heck of a long time" refers to the time elapsed since the initial release of OpenBSD in July 1996. Patches for vulnerabilities are listed per release on https://www.openbsd.org/errata.html https://www.openbsd.org/errata.html
tialaramex 6y ago
One example that is in my wheelhouse was illustrative of the not-always-clever attitude of OpenBSD to security. If you need certificates from the Web PKI (for your SMTP server, or your IRC server, or any other TLS server, but most obviously your web server) you likely want to talk ACME to Let's Encrypt or another CA. The popular way to do this is Certbot, a program written in Python. Clearly that's a lot of dependencies and thus potential attack surface area so not ideal. A popular alternative is acme.sh which is Unix shell code. So this is potentially a far smaller attack surface but shell is hardly the most auditable or secure language by default... OpenBSD ships acme-client which is written in C. Now, acme-client uses lots of OpenBSD flavour tooling to improve on its security, components of acme-client are sandboxed off from themselves and the rest of the system using pledge() and so on such that components with access to your private keys are not also doing TCP/IP. On the surface then although it's written in an unsafe language this looks like a good trade and it exactly fits OpenBSD's approach. However, the thing about ACME is it's built out of existing standard components such as Certificate Signing Requests. So instead of attack surface in Python, or Bash, or C, and trying to mitigate it with local sandboxing, you can choose to hand the CSRs to a completely separate system and so to literally airgap your private keys and all the TLS server code from your ACME implementation if you want. You can use CSRs with Certbot, you can use CSRs with acme.sh, but, they aren't an option with OpenBSD's acme-client at all. acme-client is the Beast so that a US President can be driven somewhere very dangerous and most likely get out of there alive - but just using CSRs is having him just make a video call and never leave the safety of the Oval Office.
- wahern 6y ago
  > However, the thing about ACME is it's built out of existing standard components such as Certificate Signing Requests. So instead of attack surface in Python, or Bash, or C, and trying to mitigate it with local sandboxing, you can choose to hand the CSRs to a completely separate system and so to literally airgap your private keys and all the TLS server code from your ACME implementation if you want. > You can use CSRs with Certbot, you can use CSRs with acme.sh, but, they aren't an option with OpenBSD's acme-client at all. acme-client uses a privilege separated process model (using pledge and unveil) so that private keys are never loaded or accessible to the network-facing process. And it's not just acme-client that does this. Most OpenBSD service daemons, like httpd and smtpd, perform private key operations in a privilege-separated subprocess. The technique won't win any awards for request throughput, but it reflects OpenBSD's "secure by default" ethos, which of course always has to be understood in the context of what they're trying to accomplish. Air-gapping the long-term account private keys for a semi-automated Let's Encrypt renewal process sounds more aspirational than anything. If you're going to attempt that, the lack of support in acme-client is the least of your problems in terms of initial and long-term operational complexity.[1] OpenBSD tools are primarily designed for the needs of OpenBSD maintainers, and secondarily for the needs of typical OpenBSD users. These people aren't trying to build the next AWS using OpenBSD, nor are they trying to secure Apple's or the NSA's proprietary key escrow system root of trust key. "Secure by default" has to be understood in that context. And so the fact other tools support more features, some of which can be used to theoretically implement hypothetically more secure systems is sort of beside the point. Moreover, a general rule of thumb is complexity is anathema to security, and OpenBSD is rigorous about providing the fewest knobs possible while minimizing administrative burden and effective risk for their typical user base. This is why the utility and pervasive use of pledge and unveil are simply incomparable to the Linux equivalents, seccomp and filesystem namespaces; and why the fact that OpenBSD services privilege separate private key operations is something most OpenBSD users, let alone non-OpenBSD, don't even realize. I don't really care about the exploit writers' opinions of OpenBSD. How many of them host and use their own public-facing web or e-mail servers? Attackers and defenders have completely different perspectives that sometimes lead to completely different opinions. And I definitely don't care about the consensus opinion of the security community considering that over the past decade the majority of self-described and even employed "security engineers" are neither experienced systems programmers nor experienced system administrators. Prowess with nmap and Wireshark seem to make for "hacker" credentials in this community. The depth and sophistication of their knowledge is about the same as many Node.js-cum-Rust programmers who write "parsers" and "servers" by stitching together a bunch of crates. That's not nothing, but I'm not going to attach much worth to their opinions regarding complex architectural or algorithmic problems. How many Kubernetes engineers can even understand the value of, let alone conceptualize or even implement, a pipelined series of network daemons that rigorously preserves backpressure? Why would I value their opinion on how to efficiently scale services when their measure of scalability and survivability is the ease with which you can throw more hardware or AWS account credits at a problem, and generate more Prometheus data sets? People who use OpenBSD over the long term know perfectly well what "secure by default" means, even when they themselves might have made different choices. [1] Not that I think air gapping is generally impossible or impractical. I've defended DNSSEC on multiple occasions for preserving this ability. And I do a lot of work with HSM, secure enclave, and smartcard integration, so I very much agree with and promote the idea of moving private key operations entirely off network-facing hosts, whether air-gapped or not. But WebPKI infrastructure tends to be operationally quite shallow and quite dynamic, making manually administered key signing operations less practical at any scale. But if someone can make it work, more power to them. In general this use case is too niche for OpenBSD to emphasize--either not enough potential utility, or invites too much complexity. The exception would be OpenSSH's recent embrace of FIDO HID USB keys, but it's not really an exception considering typical interactive ssh workflows, and considering the implementation complexity relative to the traditional ecosystem involving PKCS#11, PC/SC, PIV, etc. I don't think those latter standards are deal killers, but I totally understand and appreciate why they wouldn't see much attention from OpenBSD developers. OpenBSD continues to embrace and enhance IPSec and IKE despite the complexity, even as they integrate Wireguard; they're capable of making context-sensitive analyses.
tachion 6y ago
You need to be aware that while pledge is a security technology, linux containers aren't. Pledge was designed as another security layer, while containers were designed as "management" or "separation" layer, but not strictly as security measure - read up on how bad is to run things as a root in a container.