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

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

On Mon, Sep 13, 2021 at 12:11 AM Dan Lukes wrote:
> 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.
Hey Ed, It seem that some people are tied to old infrastructure.
Fallback to Port (or custom Kernel / Base?) seems reasonable. Will
there be any alternative solution after upgrade or people will be
forced to leave FreeBSD? Things start to look dramatic :-)

What is the best and worst case scenario of the change?

Is it only Base or also Kernel change?

Would it be possible to use custom build of OpenSSH server (i.e. from
Ports) with old algorithm enabled so it could work in place of the one
being upgraded in base? I can see this approach seems to work for
various services and utilities.

Port seems easiest way to provide alternative solution?

That way we would have secure solution by default and less secure
custom solution but still easy to maintain when there is no other
choice?

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info