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

> 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

Best Regards, Markus

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>

Thank-you Ed, for providing a window for discussion.

As much as I strongly agree with Dave Cottlehuber , there is sadly a
pragmatic dimension.? So, off by default goes some way to improve the
world, but folk do appear to need to be able to connect to "antique"
equipment that they have no mechanism to upgrade (perhaps call for an
ISO27001 audit? ;) ).? We really don't want to loose FreeBSDers for this.

Minor point -? your ssh command line was helpful as it confirmed
connectivity to an older FreeBSD9.1 system (still in use from 2014)
using ed25519, and finally, to clarify that putty 0.75 (from May 2021)
uses rsa-sha256; current version is 0.76, per
https://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html