4 ms·

> FreeBSD also re-enabled insecure encryption ciphers in their build after they were disabled upstream, with backward compatibility apparently being more import

> 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!

GekkePrutser 4y ago
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.
crest 4y ago
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.
- rovr138 4y ago
  I'm curious about how this is handled in the Linux world. For example, how does Debian handle this? Debian has testing, then it freezes and it moves to stable. - Debian 9 (Buster) was released in July 2019 [1] - Debian 9 is LTS supported until June 30, 2024 [2] Looking, it seems 12.0 was released in December 11, 2018 [3]. From a note on the Wikipedia page, > The timeline shows that the span of a single release generation of FreeBSD lasts around 5 years So comparing against Debian looks like a fair comparison. [1] - https://en.wikipedia.org/wiki/Debian https://en.wikipedia.org/wiki/Debian [2] - https://wiki.debian.org/LTS https://wiki.debian.org/LTS [3] - https://en.wikipedia.org/wiki/FreeBSD_version_history https://en.wikipedia.org/wiki/FreeBSD_version_history
  - kbenson 4y ago
    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.
Bancakes 4y ago
If you're running old, unsupported software whose only purpose is to drag technology back, your "shit" is already "broken".
Athas 4y ago
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.
- froh 4y ago
  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!
  - Athas 4y ago
    > 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.
- speeder 4y ago
  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.
ogogmad 4y ago
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.
- AlexanderDhoore 4y ago
  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.
  - bombcar 4y ago
    The best kind of backwards compatibility- designed to forever trip up the newbies who dare to assume all means all.
  - blahgeek 4y ago
    > -Wall is effectively frozen and new warnings are never added to it, in the name of backward compatibility. Any reference on this? Thanks!
  - tedunangst 4y ago
    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.
croes 4y ago
If you are so anal about running old software, the knobs are there to make adjustments. For the rest of us, stop making shit unsecure!
- RedShift1 4y ago
  Fair enough
jen20 4y ago
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.
- junon 4y ago
  Yeah the fact it is the top comment is concerning.
- kastagg 4y ago
  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.
  - jen20 4y ago
    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.
z3t4 4y ago
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...
ShowalkKama 4y ago
about:config search for "require_safe_negotiation" and toggle it to "false". This will allow firefox to use broken ciphers. (you might need to toggle a different option but I forgot the name)
outworlder 4y ago
> For the rest of us, stop breaking shit! The flip side is that shit will work. For everyone. Even people you didn't even know and that should not have access to said shit. Cyphers are not deprecated daily. They live on for many years.

GekkePrutser 4y ago

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.

crest 4y ago

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.

rovr138 4y ago
I'm curious about how this is handled in the Linux world. For example, how does Debian handle this? Debian has testing, then it freezes and it moves to stable. - Debian 9 (Buster) was released in July 2019 [1] - Debian 9 is LTS supported until June 30, 2024 [2] Looking, it seems 12.0 was released in December 11, 2018 [3]. From a note on the Wikipedia page, > The timeline shows that the span of a single release generation of FreeBSD lasts around 5 years So comparing against Debian looks like a fair comparison. [1] - https://en.wikipedia.org/wiki/Debian https://en.wikipedia.org/wiki/Debian [2] - https://wiki.debian.org/LTS https://wiki.debian.org/LTS [3] - https://en.wikipedia.org/wiki/FreeBSD_version_history https://en.wikipedia.org/wiki/FreeBSD_version_history
- kbenson 4y ago
  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.

Bancakes 4y ago

If you're running old, unsupported software whose only purpose is to drag technology back, your "shit" is already "broken".

Athas 4y ago

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.

froh 4y ago
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!
- Athas 4y ago
  > 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.
speeder 4y ago
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.

ogogmad 4y ago

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.

AlexanderDhoore 4y ago
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.
- bombcar 4y ago
  The best kind of backwards compatibility- designed to forever trip up the newbies who dare to assume all means all.
- blahgeek 4y ago
  > -Wall is effectively frozen and new warnings are never added to it, in the name of backward compatibility. Any reference on this? Thanks!
- tedunangst 4y ago
  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.

croes 4y ago

If you are so anal about running old software, the knobs are there to make adjustments. For the rest of us, stop making shit unsecure!

RedShift1 4y ago
Fair enough

jen20 4y ago

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.

junon 4y ago
Yeah the fact it is the top comment is concerning.
kastagg 4y ago
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.
- jen20 4y ago
  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.

z3t4 4y ago

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...

ShowalkKama 4y ago

about:config search for "require_safe_negotiation" and toggle it to "false". This will allow firefox to use broken ciphers. (you might need to toggle a different option but I forgot the name)

outworlder 4y ago

> For the rest of us, stop breaking shit! The flip side is that shit will work. For everyone. Even people you didn't even know and that should not have access to said shit. Cyphers are not deprecated daily. They live on for many years.