Important note for future FreeBSD base system OpenSSH update

[Karl Denninger]

On 9/12/2021 10:02, Markus Falb wrote:
>> On 09.09.2021, at 20:01, Ed Maste <emaste at freebsd.org> wrote:
>>
>> OpenSSH will disable the ssh-rsa signature scheme by default in the
>> next release.
>>
>> ...
>>
>> To check whether a server is using the weak ssh-rsa public key
>> algorithm, for host authentication, try to connect to it after
>> removing the ssh-rsa algorithm from ssh(1)'s allowed list:
>>
>>     ssh -oHostKeyAlgorithms=-ssh-rsa user at host
> FWIW, some of us may already have dealt with that.
> FIPS enabled RedHat Enterprise Linux (and probably other FIPS enabled
> systems) means effectively no ssh-rsa signature available in the sshd.
> I had that situation at the beginning of the year.
>
> As mentioned, ssh-rsa signature algorithm will stop working, but
> that does not automatically imply that every RSA key must be
> changed to something other. The signature algorithm is not a
> property that is inherent to the key.
>
> That said, existing RSA keys were working fine for me (my openssh
> client was rsa-sha2-256 and rsa-sha2-512 capable) but when I tested
> with some popular windows clients (filezilla, putty) it failed
> (apparently no rsa-sha2 algorithms available).
>
> I found it interesting that mentioned clients were ecdsa
> capable but did not support sha2 signatures with RSA keys.
> Maybe the situation changed in the meantime to the better.
>
> There are 3 scenarios:
>
> 1. both sides support rsa-sha2 signatures -> RSA keys still working
>
> 2. one side does not support sha2 signatures but does support other
> key types -> you can change key type
>
> 3. one side does not support sha2 and no other key type -> you loose
>
> A prominent candidate for 3. would be Cisco IOS

This has come up before with web browsers and is a serious PITA when 
there is no override available for those who need it on a targeted, 
specific basis.

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.

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?

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20210912/52f34bcf/attachment.bin>