> FreeBSD also re-enabled insecure encryption ciphers in their build after they were disabled upstream, with backward compatibility apparently being more important to them than the security of their users.
You know what? I appreciate that. The security people want to break stuff all the time and it is terribly annoying to have to go and fix stuff. Sometimes you even can't, there is software out there that only supports older TLS ciphers and you have to keep an old browser around to access it. And inevitably that old browser is going stop working at some point too... If you are so anal about security, the knobs are there to make adjustments. For the rest of us, stop breaking shit!
If something is broken in the default installation, you'll notice quickly during acceptance testing and can go and fix it (for example by re-enabling insecure protocols).
If something is unexpectedly insecure, you will probably not notice until it's too late.
I think the admittedly annoying security people are right in this instance.
Well... I had some serious issue where security-related breaking changes sent a whole business down for days, with severe lost revenue, without any way to go around it, because the software that needed the insecure old algorithm was government-provided and mandatory for transactions...
It is not like you can go and tell your government you won't pay your taxes because their tax system doesn't work on newest OS version because it is outdated... Or rather, you can, and then the government will happily shoot you.
still how do you give the user the option to say "I know what I'm doing."
I get that access to an unknown site with unknown content with a dated cipher should _by default_ break. By default!
I do not get that I cant't access a well known site any longer because that site that I don't control just doesn't update their cipher. In that latter case I need to and want to be able to override the default recommendation of the gurus --- without having to rebuild my client!
> still how do you give the user the option to say "I know what I'm doing."
You make configuration available. Most of these disabled-by-default protocols can be enabled by a user who really knows what they are doing (and isn't just saying so). A few might have been outright removed from the code base. In that case, you really need to know what you are doing, but you can still bring them back by installing a custom patch or downgrading the program in question.
I think it is a good idea to create friction along pathways that are probably mistakes. The people who really need to go down that path will put in whatever effort is necessary, while people who are motivated by the path of least resistance will be nudged in a safe direction.
Security expert love to discuss ciphers but how commonly old ciphers are exploited by threat actors in real world?
I heard cryptographic weakness are sometimes used to break tivoization/DRM but I don't consider people who do this threat actors - an owner should be free to run any software on own hardware. And an attack on device you hold in hands is completely different than say an attack on remote FreeBSD server.
I'm one of those security experts. I've broken more cryptosystems than I can count through security & code reviews. You would be surprised how many vendors have no idea on how cryptographic primitives work or when/how to use it. This is exactly what we mean when we say "don't roll your own crypto".
There is a communications problem within all of this. If I break a cryptosystem, I do not have permission by either party (customer/employer) to go and write a blog post about it. All in the name of "protecting our users". The same goes for my colleagues around the world, as such it gets very little attention.
As for threat actors misusing it, there is a value/effort calculation in their world where it is often easier to access content through other means. Crypto is hard - for everyone, even threat actors - so you won't often see them trying to tackle it.
IIRC FreeBSD changed the default value to keep the old crypto enabled by default in a minor release after they imported a newer OpenSSH version. They imported the new OpenSSH release because the old one was uncomfortable close to end of life to include in a new release and they changed the default cipher selection to a less secure one to maintain compatibility within a major release. If minor releases locked people out in the name of "you shouldn't be using this anyway" fewer people would install them in production. You would end up with more end of life systems in production, because nobody dared to touch them. Oh and if you do it often enough most users will migrate to a saner platform.
There is no one answer in the linux world. It's distro dependent, with different distros choosing different policies which you can choose from to match what you're looking for.
For example, Fedora will upgrade package versions and defaults often, because they release often. RHEL, which is made from a frozen Fedora version (for the most part), won't even upgrade versions of installed packages, but will instead back-port fixed into the old versions, so you are ultimately as stable as can be expected from running an OS, as without new versions and new features in packages there's little to worry about with regard to changing behavior.
Usually, that means you're responsible for knowing what to set for package defaults, and while they might change the default for a package such as OpenSSH at a point release (or in critical situations as a normal update), the way their config management works is that your existing systems will likely not see any change, but a new install might (there are different actions in different situations, but it's documented).
The main exception to the above is point releases, which are every six months or so, where they may take a subset of packages and allow newer versions of those to allow for new features, but with copious amounts of testing to hopefully catch any problems that might introduce. In some cases they may deem it safer to back-port a feature than to change the shipped package to a newer version (this is common for some kernel features, for example).
What this means in practice though is that you can choose to do regular security and bugfix updates automatically but stage and test point release updates, and do one or two systems to test whether it introduces problems.
Those are the benefits of an enterprise distributions, such as RHEL (and free derivatives such as CentOS and Rocky Linux) and Ubuntu LTS releases. The downside, if you can consider it that, is that they are so stable that five years later you'll find you're still running that same distro and your problem is that that majority of the software stack you're running is very old, and the annoyances from that continue to mount, and harder to migrate to something newer because there's been so much change in all the software that you can't assume that the configs will work cleanly.
Software's an area where fail-fast/fail-hard is commonplace advice. People often compile their code with -Wall. Secure defaults are like -Wall.
Security's a thankless area since you have no way of knowing which exploits were prevented by security measures. It's like precautions against fires: You have no way of knowing how many thousands of deaths were prevented by measures taken to prevent fires from starting - and you never will. It even affects our politics: We don't know how many deaths were prevented by the measures taken to save lives from the present pandemic, and as a result some people complain.
It's funny that you chose -Wall as an example because it is the exact opposite of what you are trying to say. -Wall is effectively frozen and new warnings are never added to it, in the name of backward compatibility.
New warnings appear in -Wall with just about every compiler upgrade. That's why standard advice is to never ship with -Werror because the next guy's compiler may fail to build it.
Indeed. And it's not like those ciphers are completely broken to the point of being easily exploitable.
I have some old servers with older iLO that suffer from this, and I'm only using them on a local network. Similarly, I have used the "None" cipher on a local network to sync a lot of data from my old NAS which definitely did speed things up (that box didn't have AES-NI, ancient processor).
They don't have to enable it out of the box but having it in there when needed is definitely helpful.
On another point, that 'huge diverging patch' from OpenBSD PF was all about multithreading and dramatically improving performance on modern systems, it's not like it was done for the sake of it... But it should have been kept more up to date, yes.
This is among the worst takes I’ve ever seen, to the point that I might adopt this as an interview question to avoid ever +1ing a hire who thinks in this way.
If you need broken old stuff to run, the onus must be on you to disable the security, not the other way around.
There are situations where "abruptly stops working" is not just inconvenient but catastrophic. To make intelligent decisions about these trade-offs it's necessary to consider possible outcomes in detail. That depends on how software is used in a larger system, not just whether it's using an encryption algorithm that is still in fashion.
When you weaponize interviewing decisions to enforce cultural homogeneity and agreement with your own opinions, you are reducing diversity and excluding people who are intelligent enough to recognize nuances that break rules of thumb.
There are cases where the rule of thumb does not apply: general purpose operating system distributions is not one of those cases.
Anyone that can explain both the trade off and when it is appropriate to make would be unaffected by this. The default must be security - we don't live in the 80s anymore.
Security can mean different things, for example a database with personal information accessible from the internet without authorization, vs a funny cat video streamed via an unencrypted channel...
The linked blog post gives the impression that little has changed, but it is very much not the case.
Taking a look at the first section, "OpenSSH Modifications" - rather little of it is current. With respect to ciphers disabled by default in upstream we may follow along in main but leave them enabled in a stable/release branch, in an attempt to avoid breaking existing users while deprecating increasingly insecure options over time. We do indeed add support for tcp_wrappers back in. With respect to the base system I think the rest of the section is not applicable.
Why is tcp wrappers still there? The overlying theme of the SSH section is about going against upstream in the name of backwards compatibility, which it sounds like FreeBSD still does (albeit to a smaller degree).
tcp_wrappers is still there because it provides functionality not otherwise available that is still used, and has a relatively small impact on the attack surface.
Well, you see, there are still some users even 6 years later that are using FreeBSD, so they can't change it yet. Maybe in another 6 years nobody will use it so they finally will be able to change it? Only time can tell!
I got as far as "HyperThreading is insecure so disable it".
There are some absurd recommendations on here (disable TCP SACK, use TCP BBR) and the weirdest of all is why anyone who hates FreeBSD security this much would still use the OS?
I mean, Greg Kroah-Hartman of Linux agrees[1,2] as far as Spectre etc. go; more generally there seems to be almost no microarchitectural isolation between HT threads on x86 implementations, so the leaks probably won’t ever really cease there.
The performance benefits of HT are also not at all universal. I mean, they do exist in some cases—if you’re running closely related scalar-compute- (or, better, dependency-) bound tasks that bang on the same small piece of memory, or if you run several things that are just bad at loading the CPU so HT-induced contention doesn’t matter. (The latter scenario was obviously much more important at the time HT was introduced, when neither people nor compilers were particularly good at optimizing for superscalars.) Or, though it’s not a performance benefit, it can help if you have few cores and the OS scheduler is bad at letting interactive tasks run in the presence of long-running batch ones or heavy swapping. But properly optimized multithreaded data crunching like video coding or compression doesn’t really run faster when given extra threads to run on HT “cores” rather than just leaving them disabled or idle.
This is interesting. The mitigations have had a major impact. Especially with the recent loss of reptoline[1] on older AMD/Intel. Maybe enough that there isn't an advantage anymore to enable SMT on some processor families?
At an old job, we disabled SMT on our hypervisor hosts in an effort to mitigate some of the security issues before patches were available. We had to roll back. Without SMT, the hosts struggled to keep up with load. If I had to quantify it, I'd estimate that we lost, at least, 30% performance by disabling SMT (probably more). Those servers were replaced before I left, but I'd be interested to compare disabled SMT to enabled SMT with all the current mitigations in place.
Unfortunately Intel sold us all a very dangerous technology that we got used to. Hyperthreading has been disabled in more security-conscious OSes like OpenBSD and HardenedBSD. Greg KH praised OpenBSD for making this decision, even if he couldn't for Linux.
Ironically, imo for servers it would make sense to leave hyperthreading turned on because a server has full control over what is installed and what is running.
I have been using fbsd almost exclusively, professionally, for 25 years - and built somewhat high profile projects (Johncompanies, rsync.net) on top of it and … there is plenty of hate in my love/hate relationship with it.
It doesn’t seem odd to me at all that this individual would continue to use freebsd while maintaining such strongly held critiques of it.
If I hated something that badly or had such security concerns about it, I'd drop it like a hot potato for a superior alternative. I just don't have time for that level of irritation or worry in my life.
For many years, I was a devoted FreeBSD user. The lack of basic security hardening found on FreeBSD as compared to other systems vexed me somewhat. When the HardenedBSD project got going, I was thrilled. "Ah-ha!" I thought. "Now I can keep using my favorite OS without feeling like security is taking a back seat."
Then I found a bug (in the base FreeBSD, not Hardened-specific) that had prevented ipfw from being used on big-endian systems for several years. Years, mind you- ipfw went for years without working on big-endian systems and nobody had noticed. That was too much, and I ran for the hills.
Now, on OpenBSD, I very much miss ZFS... but that's a small price to pay in my book.
I figured OpenBSDs argument against ZFS was the licens. It makes sense that they would want to audit the code before importing it into base, and it can’t be a kernel module, given that OpenBSD yanked that feature years ago.
For reference, this was several years ago- 2015 or thereabouts. The FreeBSD project has since added or improved various security features (or made them more accessible) directly as a result of the work from and/or the pressure exerted by HardenedBSD.
This was not the case early on, and to my memory, in the early days of HardenedBSD, the relationship between the two groups could have generously been described as acrimonious. For an example, see the ASLR-on-FreeBSD debate.
Not much of a debate? You either take contribution feedback or you don't contribute. When I open a PR to some open-source project, and maintainers/contributors give me feedback, I incorporate it and don't throw a tantrum.
Everything aside, ASLR is present since 13.0 and default in 14.0. Different implementation. Usefulness of ASLR in general is another debate.
Even as a FreeBSD "fan" I have to admit that there are some valid points in his rant e.g. the threaded AES-CTR did introduce a slightly larger attack surface to bugs hidden by OpenSSH opting to use only processes.
I still preferred filling my multi-Gb/s pipes with backups for an hour or two every night instead of having replication take most of the day at ~300Mb/s. I need backups to be replicated nightly off-site before the start of business. The largest single backup job alone would have been too slow to finish in time after a busy day over unpatched SSH. I needed a tool that's fast enough to finish transfers in the available time window. Had FreeBSD shipped an unpatched SSH I would've had to implement most of its core features in something else instead of running a multi-threaded implementation of the same symmetric ciphers.
I've been using FreeBSD for 26 years on personal servers. I think there's merit to going through this and deciding whether to agree or not with changing certain defaults. I have similar changes on machines, though not as aggressive as the article suggests.
That’s true but like I said, rightly or wrongly (and maybe I am wrong to dismiss it), I can’t be bothered with it.
This is a nice way to write if you want to let off steam, or have an argument on a site like this, but if you’re trying to influence people it’s not gonna work.
Sadly, yes. If his goal was actually improving real-world security...well, with less than the effort level he seems to be putting into this, he could write a "config-audit" script, which would read through a FreeBSD system's config files, and make well-explained recommendations for improvements. From a quick look at the FreeBSD Ports, I doesn't see anything like that.
Many of the claims on this page are supported with links to commits, mailing lists posts, etc. However then there is this claim, which lacks any link supporting it:
> FreeBSD's malloc (jemalloc) is very forgiving of buggy/hostile code compared to something like otto malloc.
Sounds vague. I'm not disputing it, as I haven't read the code of the two mallocs. But I would be curious about the details. Does anybody know what that's about? I was under the impression that jemalloc was seen as quite robust, not least thanks to doing away with free-lists (which is also true for otto malloc, as far as I can tell from cursory research).
If you actually read the thread that response is taken from (starting at https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01...) you'll see a wholly different picture: a FreeBSD developer proposed a change, there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made.
The FreeBSD src git repo has hundreds of thousands of commits, and anyone can post to mailing lists, so of course it's possible to find examples of mistakes being made, or misguided posts from developers or users.
I very much welcome constructive criticism and ideas for improving the security landscape within FreeBSD.
> there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made.
Help me understand here. The reply by Julian is a huge overreaction. The text you quote seems to be condemning him (a user, not the developer) for fighting a seemingly worthwhile change on the principle of it being the way it was for a long time.
So doesn't that kind of prove the point that you're saying isn't true?
The blog post offers the linked reply to support the claim that FreeBSD "blatantly disregards security in favor of performance and appeasing their enterprise consumers."
Dragonfly has superior architecture, performance and security, despite its much smaller team. It is a textbook example of how a small team of focused competent engineers will deliver higher quality than an heterogeneous large body of developers with no focus. They are actually scaling in a manner competitive with Linux, unlike the other BSDs.
When Matt left Freebsd, which was due to a conflict that spawned over bad technical decisions, many good developers followed him.
What was left did implicitly support bad decisions. Fine-grained locks for SMP do explode complexity and makes writing quality code that much harder. It is also a problem in Linux, which compensates with sheer manpower.
Freebsd has been a cesspool since then. Jesus, what a mess Freebsd has become.
Can you confirm that Dragonfly has all of the CPU vulnerability mitigations that Linux has, including Retbleed, Spectre V1, and Spectre-BHB? FreeBSD does not have those three.
It would also be good to read about Dragonfly's exploit mitigations. Are these documented somewhere?
The wikipedia article has a history[0] of releases. Meltdown and Spectre mitigation support are mentioned in 5.2.
I know there have been new CPU vulnerabilities found past these, but I haven't been keeping track closely.
It would help if they had an announce mailing list. Looking at older release notes seems to be a manner of digging through the users list, or guessing URLs based on the current release notes. They seem in dire need of a maintainer for the website.
No, FreeBSD is really only one distribution which is a big plus IMO. The GNU/Linux world is very fragmented because of this.
Now, there are some spinoffs like DesktopBSD, GhostBSD and HelloSystem but they're very small compared to the situation with Linux where there are several major distros.
But if your focus is security, OpenBSD would be a good alternative for sure.
I see a lot of negative and dismissive comments from you in this thread. Perhaps you'd care to quantify some of the things you say are wrong. I'd also recommend against ad hominem attacks against someone who wrote an article you disagree with.
The "hardening" menu in the installer is pretty pathetic if we're being honest. "enable /tmp cleaning"... wow. I'm secure now.
The FreeBSD release building tools [1] support customisation. You can either patch the defaults in the code or include different default configuration files. Don't take this rant too seriously.
You know what? I appreciate that. The security people want to break stuff all the time and it is terribly annoying to have to go and fix stuff. Sometimes you even can't, there is software out there that only supports older TLS ciphers and you have to keep an old browser around to access it. And inevitably that old browser is going stop working at some point too... If you are so anal about security, the knobs are there to make adjustments. For the rest of us, stop breaking shit!