Hope to release wireguard on FreeBSD soon as well.
In order pfSense to include it: https://redmine.pfsense.org/issues/8786
Available as a Port / package:
Running it in a jail for further compartmentalization:
Was satisfied with the state of affairs before but genuinely excited about this development.
It is important to remember though that it is not the number of users but but the value of the compromise that determines how compelling the O/S is. There are like vintage mainframe O/Ses for which folks are actively developing compromises because some government or telco hasn’t migrated off. Then again, those teams aren’t going to waste a exploit on somebody’s home Usenet archive.
TL;DR: nevermind. I am too busy arguing with myself to be coherent.
Here's an excellent talk (in website form) on the subject: https://isopenbsdsecu.re/about/
Quite frankly it reads like someone with an axe to grind against openbsd.
Here's a material example: OpenBSD has expended considerable effort into removing ROP gadgets from their compilation products.
As the website documents, these efforts haven't made a single exploit harder to write.
GCC even removed their (mostly equivalent) ROP mitigation approach, documenting it as "fairly ineffective" and "lur[ing] developers to the land of false security".
(Another good example is PID randomization: OpenBSD added this over 20 years ago as part of their "randomize anything that can be randomized" approach. It's never had any real positive security impact, and has made other PID-based vulnerabilities more viable.)
That being said, I think Linux’s guts get far more attention than OpenBSD’s do, and that the (fewer) mitigations that Linux chooses to implement are much better supported by both information on real-world attacks and by the literature. Given that, I have a slight preference for Linux. But that shouldn’t be taken as praise.
After a while, mktemp got more usage (which is good) and $RANDOM became available for scripts and so forth, but the situation was quite bad 20+ years ago as far as vendor installation scripts went.
Perhaps exactly noone was saved on OpenBSD because few installed linux-compat Netscape 1.1N for i386 with a bad installation script while having adversarial users logged in, but there is no reason to be equally bad as the then-more-popular OSes who did see /tmp races being won by users.
At any rate, I think some people may forget what stock Linux distros or even a commercial *nix install used to look like at the default install, before people like the OpenBSD folks raised awareness of some of these issues. In the late 90s I recall default installs elsewhere that had a bunch of ports open and no firewall right out of the box in a default install. In the same timeframe OpenBSD was making a bit of a PR-ish stink about a secure default install. In the same timeframe OpenSSH came on the scene.
But honestly, there are a few things that OpenBSD is only really just starting to get really right in the last few years. syspatch and pkg_add-able binary updates in the stable branch are two that come to mind. Also sysupgrade; I used to dread upgrading OpenBSD [xkcd had the joke about it leading to shark attacks], but now it's really simple.
I especially like the part where it lists people who helped but it's all redacted. All of this "research" came from google and twitter. I'd like to see some bypasses to OpenBSD's mitigations and perhaps some ideas and/or code to help improve them or implement ones that these folks say work better. If they're all so bad then it shouldn't be hard for someone like the author or so called security experts he quoted to do these things. Yeah, maybe no one is going to pay for that work to be done... that seems to always be the response when someone asks for proof, code, etc. No one has the time. They sure spend enough time making websites, blog posts, and tweeting about it though.
I personally feel that OpenBSD is more secure for my use case, but I’m happy that people bring up points like this as humans make mistakes and not even OpenBSD is perfect.
I don't think OpenBSD has perfect security and I'm not sure why that needs to be said. I don't see anyone involved in the project making that claim either. What I'm saying is this talk/website is just as dubious as some of y'all think OpenBSD mitigations are and if that's not obvious from looking at the sources I'm not sure what else to say here.
Just as a guide telling you to "chmod 600 webserver.key" doesn't really state anymore that it tries to protect non-webserver access to the https key, because it is implied that removing random access to the key (or to non-useful syscalls in the case of pledge) means the threat was unexpected reads of the key by someone who shouldn't be allowed to do just that. No assessments would be found to say "chmod'ing 600 removes 56% of the unexpected read attempts, Posix ACLs 9% more, apparmor another 14%, and correct SELinux tags will stop upto 96% of the keyfile reads by the wrong user".
If my wildly invented numbers were right would anyone suggest only using SELinux and leave keyfiles at chmod 777?
One can then put up an angry webpage claiming people who chmod their keys are crap at security, it is uneffective, no listing of what it even was meant to protect against and of course no hard numbers to it. But 0600 would help you the day some junior admin turned off selinux on the webserver because random HOWTO said colorls works better with it off.
Does that improve security? By how much? What exploitation would it have prevented? At what cost? If you're not measuring the impact then it's pretty much voodoo security.
> Just as a guide telling you to "chmod 600 webserver.key" doesn't really state anymore that it tries to protect non-webserver access to the https key, because it is implied that removing random access to the key (or to non-useful syscalls in the case of pledge) means the threat was unexpected reads of the key by someone who shouldn't be allowed to do just that.
Then that guide is of little practical use. On a multi-user server that chmod makes sense. Inside a single-user container/VM, it's completely pointless. If the guide isn't telling you what the threat model is, you have no idea whether the mitigations you're applying are relevant or not.
> No assessments would be found to say "chmod'ing 600 removes 56% of the unexpected read attempts, Posix ACLs 9% more, apparmor another 14%, and correct SELinux tags will stop upto 96% of the keyfile reads by the wrong user". If my wildly invented numbers were right would anyone suggest only using SELinux and leave keyfiles at chmod 777?
Yes! Of course. Would you not?
> But 0600 would help you the day some junior admin turned off selinux on the webserver because random HOWTO said colorls works better with it off.
If you think that's a real danger then include it in your threat model. Maybe SELinux is harder to understand, or configure, or too many people have access to its settings. Maybe it's the opposite (I've seen junior admins chmodding everything to 777 many times, I've yet to see one turn SELinux off). Either way, you need to explain that so that people understand it, otherwise you're encouraging people to cargo cult their security practices.
> OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make. Also, since OpenBSD is exported with cryptography, we are able to take cryptographic approaches towards fixing security problems.
> ASLR: OpenBSD 3.4 [Nov 2003] was the first widely used operating system to provide it by default.
> W^X: First used for sparc, sparc64, alpha, and hppa in OpenBSD 3.3. Strictly enforced by default since OpenBSD 6.0: a program can only violate it if the executable is marked with PT_OPENBSD_WXNEEDED and it is located on a filesystem mounted with the wxallowed mount(8) option.
> Kernel relinking at boot: the .o files of the kernel are relinked in random order from a link-kit, before every reboot. This provides substantial interior randomization in the kernel's text and data segments for layout and relative branches/calls. Basically a unique address space for each kernel boot, similar to the userland fork+exec model described above but for the kernel. Theo de Raadt, June 2017.
BIG citation needed.
> Not sure it makes a difference over Linux
Edit: listen, I understand that people are religious about their operating system kernel, but please make a reply to these points if you have one to refute.
> BIG citation needed.
While it may be debatable how much of an effect the OpenBSD security culture has on real world security outcomes, it is pretty obvious to most people I think that OpenBSD has a culture of security (or a focus on it) that Linux simply does not have. Security is practically the entire branding of the project. Just go to its home page, literally the first sentence is an advertisement for its security record. The culture is very much there, regardless of results.
Now, if you did want to argue that the security culture does not necessarily result in better outcomes, 1) that intention should probably be made more clear, and 2) why not at least provide an argument or some amount of evidence for it?
And then look at the same number of security advisories for the Linux kernal during the same time:
And then remember that NOBODY uses OpenBSD.
Literally no big-time company uses OpenBSD. Who uses OpenBSD??? Literally nobody.
In aggregate they will serve/distribute 34 GB/s.
This is a business-critical workload.
Would you put this on OpenBSD? And if so, who would you call when it breaks?
Would you put this on FreeBSD? And if so, who would you call when it breaks?
We put this on Linux. And we can Red Hat when it breaks.
It has broken for us in the past. And we get absolutely top-notch Linux kernel TCP experts on the phone to help us fix the issues in no time.
Oh and load-balancer..Jupiter OS is based on FreeBSD, pfsense and Opnsense(HardenedBSD), Netflix, Cisco, Sophos, Stormshield and so on:
PS: If you serve 34GB/s you should probably have your own 'top notch' TCP experts ;)
On Linux, I won't even start on the policy on most distros.
Personally I see this as the most exciting thing to happen to linux in the past 2 - 3 years.
I'm really pleased to see ongoing Wireguard integration in all the big platforms.
The setup is so simple, I route all my personal traffic through a simple cloud based WG + Pihole setup.
There's an ACME (e.g. for Let's Encrypt) client included in OpenBSD which is exactly what you'd expect a real man ACME client to look like. It uses OpenBSD-only pledge() and similar features to do privilege separation, it has guards and checks throughout and so long as there aren't any missing (but there's no way to verify...) it's probably safe to use it - but it's written in C rather than a safer language.
There are some obvious security considerations you'd put in an ACME client, and somebody who thought OpenBSD was about security would probably expect them. But they are absent because it's not about security it's about being a real man. Examples: Using CSRs is safer as now the ACME client doesn't know your private keys, but acme-client doesn't provide any way to do that. Using the dns-01 challenge rather than http-01 or tls-alpn-01 allows you to do issuance from a system that isn't accessible from the outside world rather than having to open ports but acme-client only supports http-01 challenges.
If OpenBSD has a culture, it’s not “real men,” but “show me the code.” That’s plain from the mail linked in the post you responded to: mailing lists are full of people making suggestions (like “rewrite OpenBSD in Rust”), but few people doing the necessary work (like implementing or testing a reasonably POSIX‐compatible userland, handling the 8+ architectures that would immediately have to be dropped, measuring the performance impacts on the project build clusters…).
Contrast the above response with the WireGuard implementation this whole discussion is about. A non‐OpenBSD contributor sent a draft patchset, which received suggestions and was iterated upon several times, and despite some complaints about the concept from one quarter (https://marc.info/?l=openbsd-cvs&m=159273877612032&w=2), it was committed by the very person who had those complaints! In the end Jason and Matt of WireGuard described the process as “extremely pleasant” (https://lists.zx2c4.com/pipermail/wireguard/2020-June/005588...). This is feedback I see often from external contributors.
You describe safety guards like privilege separation and pledge/unveil as “real men programming”, but they’re the complete opposite: they exist precisely to mitigate the damage that results from human error. acme-client’s design does keep private keys inaccessible this way (see https://kristaps.bsd.lv/acme-client/). Privilege separation is a proven technique. OpenBSD is not a project that says it’s okay to live dangerously as long as you code with the right macho attitude.
There are plenty of valid things in OpenBSD to complain about—it might even be valid to argue that our resistance to Rust disproportionately values architectural concerns over memory safety!—but don’t blame “real men programming.” That’s just false.
I am baffled as to why you attribute OpenBSD’s ACME client lacking DNS challenges to this same “real man” attitude rather than the simple reality that in a relatively small, completely volunteer project nobody has yet done the work to integrate that feature. If someone sent a patch to add dns-01 support—certainly something very useful that plenty of our users and developers want—I bet it would be committed within weeks.
OpenBSD is for REAL HUMANS. Not real "men". OpenBSD is build and designed for everyone. It is a system you can give to your 5 year old and as they learn how to use the computer they'll learn how to safely connect to the Internet. The base install literally comes with games targetting children, to help their Internet experience.
Your whole life you have been using non-free, non-functional, and insecure software.
I'm here for fun - if we want to keep as many pufferfish alive as possible until the heat death of the universe, for me it starts with installing OpenBSD. OpenBSD is nothing other than love for other humans, and we don't know if we can trust them.
My little cousin 9 y/o ...he knows how to update the system and packages, he plays with it very often and started to type some python programs i send him..often he tweaks them..like changing the color of the square. He has so much fun when he can 'magically' change whats drawn on the screen. Thank you all for that great system
Just as maintainers do, contributors do not want to waste their time. If people talk, without code, about say dns-01 preferrable to http-01, that is because they aren't sure sending a patch to add dns-01 support without discussion would be merged. As an OpenBSD developer, you have such visibility and I believe you, but it is often very unclear to outside contributors whether something will be merged if implemented.
Saying "show me the code" to such discussion in practice is interpreted as "I am not sure whether we want this or not, but if you do the implementation, it is your timee wasted, not mine". The reason is, if you interpret it as "show me the code and you will be welcome", your guess is often wrong. After a couple of such experiences myself, these days I never do advance code payment. Always discussion first.
There should be no need for your ACME client to have access to those private keys in the first place. That's what I'm highlighting.
If pledge works 100% in OpenBSD and if the acme-client C code is bug-free - neither of which is likely much less certain - then it's exactly as safe in this respect as a dozen other ACME clients using CSRs otherwise it's worse.
But you described privilege separation as “real men programming,” and that’s off base.
I am (sincerely!) interested in what Let’s Encrypt clients you suggest that use http-01 and don’t require access to private keys.
CSRs were sufficient for that, at no point was it necessary to ship private keys. And this was using just the standard ubuntu certbot for the actual requests.
Pretty backwards of Theo to snub Rust-lang like that. It's pretty much attempting to achieve the same ideals as some of OpenBSD's.
For example, for a time OpenBSD was trying to switch to pcc, a super simple C compiler so they could get off gcc. They eventually went with clang instead, which is not simple, but presumably the cost of using an alternative to gcc or clang was too high.
It was also written 3 or so years ago, so hopefully rust has improved.
I think they already have enough trouble with Rust in the ports tree that they don't want the same thing in base.
If wireguard doesn't meet your requirements, don't use it, but its kind of rediculous to complain it doesn't do X when doing X would defeat the point of the software.
The OpenBSD kernel module is also written in C: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_wg.c...
But the code looks quite different from https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireg...
That goal may be antithetical to a single codebase supporting multiple (possibly very dissimilar) operating systems.
It's interesting to compare this approach to the approach taken by OpenSSH (and its openssh-portable variant). One has code specific to each OS, the other one has one canonical codebase for one OS + patches addressing compatibility with other OSes. IMHO mostly due to the difference in complexity of each project.