freebsd security - Sep 2021 - Important note for future FreeBSD base system OpenSSH update

> On Sep 12, 2021, at 7:40 AM, Karl Denninger <karl at denninger.net>
wrote:
> 
> I have in the field a BUNCH of "smart" rack power strips that
have this problem; their management firmware does NOT support more-modern cipher
sets and SSL requirements.  I get it, those older SSL versions are insecure and
we know it.  But when the browser people all decided to kill the ability to
connect to such servers with no override (that is, don't warn, DENY with no
option to get around it) all of a sudden logging into those strips to change
(for example) the name of a socket, the alarm limits and similar became
literally impossible.  Contacting the manufacturer resulted in a middle finger
back; "nope, we're not releasing new firmware for that."  I've
seen the same thing with some older OOB management interfaces on server boards;
they won't take an acceptably-long (by modern standards) HTTPS server key,
and thus, same problem and same answer from the manufacturer.  These are
perfectly-serviceable devices in their application and quite-expensive to
replace when there's nothing wrong with them. On the server boards by now
they've all been retired as people decided the better power budget and
performance levels made changing them (and re-purchasing the RAM that went on
them, which for larger servers is a non-trivial part of the total expense) a
reasonable proposition.  This of course is not true for a smart power strip in
the rack and makes both monitoring of energy and remote-hard-power-cycle
available without a physical site visit or remote hands.
Blaming the browser and other client providers (OpenSSH, etc) for a problem that
is 100% because the devices are now abandoned by the manufacturer is the wrong
place to focus your anger. We have an enormous problem in the industry of crappy
embedded devices (like the OOB management plane) accruing technical security
debt while the manufacturers give "a middle finger back" as you say.
The supportability of the hardware needs to be baked into the purchasing
decision. Commitments from the manufacturers on supportability timeframes are
important to understand and budget into a hardware refresh cycle.
> In the case of the power strips the "answer" was one of the
prepackaged, self-contained old "portable" versions of FireFox which
complains but the alert can be clicked through.  I recognize that exposing those
devices to the Internet is unsafe but have never trusted that anyway;
they're behind a gateway box with no port hole punch and if I'm
VPN'd in then it's not possible for a random person to screw with it.
> 
> It would be sad indeed if the only answer here is "load up a partition
with an older copy of FreeBSD on some device and use that."  Can we avoid
that being the answer, as it became with the browser issues?
You are already accepting the risk of continuing to run devices with known bad
configurations. What's the problem with keeping that old FreeBSD host around
as well, it's just one more risk acceptance for issues that are pretty much
the same as what you are already accepting? Alternatively, compile and install
an older OpenSSH version on well-maintained host in a dedicated prefix which is
only used for that purpose.

We do need to remove the code entirely as putting it behind a compatibility or
some other "scary things are here" flag will guarantee that
manufacturers don't try to update their codebases to work with modern
protocols; they will just provide instructions on how to enable scary mode and
move on. In the interest of protecting everyone, we need to remove this code and
put it into the dustbin of history.

Best,
Gordon

On 12.9.2021 23:27, Gordon Tetlow via freebsd-security
wrote:
> Blaming the browser and other client providers (OpenSSH, etc) for a 
> problem that is 100% because the devices are now abandoned by the 
> manufacturer is the wrong place to focus your anger. We have an 
> enormous problem in the industry of crappy embedded devices (like the 
> OOB management plane) accruing technical security debt while the 
> manufacturers give "a middle finger back" as you say. The 
> supportability of the hardware needs to be baked into the purchasing 
> decision. Commitments from the manufacturers on supportability 
> timeframes are important to understand and budget into a hardware 
> refresh cycle.
"One size fits all" may be acceptable approach for unskilled home
users,
but not for professional use. The security mechanism may be secure 
enough for particular use even if there are known issues with the method 
in question.

There may be a various reason to abandon particular method/algorithm but 
don't claim it's for my security because it's just not true. If 
particular algorithm is not secure enough for me I'm not using it 
despite it's supported. If algorithm is the best for particular case 
(it's why I'm using it) the removal will decrease overall security of 
such system.? In no case the security will be increased.

We should avoid to make decisions on behalf of skilled security officer 
familiar with particular use case.

Just my $0,02

Dan