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

We now have OpenSSH 8.7p1 in the base system and I will MFC it to
stable branches soon. (FIDO/U2F support is one of the most anticipated
new features available in this OpenSSH version, but it is not yet
enabled in the base system - additional work is ongoing.)

There is an important caveat to be aware of for the next base system
update though - I've reproduced it below (from OpenSSH's release
notes, https://www.openssh.com/releasenotes.html).

The notice includes a command to run to determine if a server will be
affected by this issue - I would appreciate it if folks can try it
with servers they use and report back, to help determine if this will
be an issue in practice and to help guide the next base system update.

Imminent deprecation notice
==========================
OpenSSH will disable the ssh-rsa signature scheme by default in the
next release.

In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1
hash algorithm in conjunction with the RSA public key algorithm. It is
now possible[1] to perform chosen-prefix attacks against the
SHA-1 algorithm for less than USD$50K.

Note that the deactivation of "ssh-rsa" signatures does not
necessarily require cessation of use for RSA keys. In the SSH
protocol, keys may be capable of signing using multiple algorithms. In
particular, "ssh-rsa" keys are capable of signing using
"rsa-sha2-256"
(RSA/SHA256), "rsa-sha2-512" (RSA/SHA512) and "ssh-rsa"
(RSA/SHA1).
Only the last of these is being turned off by default.

This algorithm is unfortunately still used widely despite the
existence of better alternatives, being the only remaining public key
signature algorithm specified by the original SSH RFCs that is still
enabled by default.

The better alternatives include:

 * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
   algorithms have the advantage of using the same key type as
   "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been
   supported since OpenSSH 7.2 and are already used by default if the
   client and server support them.

 * The RFC8709 ssh-ed25519 signature algorithm. It has been supported
   in OpenSSH since release 6.5.

 * The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These
   have been supported by OpenSSH since release 5.7.

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

If the host key verification fails and no other supported host key
types are available, the server software on that host should be
upgraded.

OpenSSH recently enabled the UpdateHostKeys option by default to
assist the client by automatically migrating to better algorithms.

[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020)
https://eprint.iacr.org/2020/014.pdf

On Thu, 9 Sept 2021 at 14:01, Ed Maste <emaste at freebsd.org>
wrote:
>
> There is an important caveat to be aware of for the next base system
> update though - I've reproduced it below (from OpenSSH's release
> notes, https://www.openssh.com/releasenotes.html).
Upstream has also made a change to have scp use the SFTP protocol by
default. This will appear in OpenSSH 8.8. You can test SFTP protocol
mode now by passing the -s flag to OpenSSH (in main/-CURRENT).

Commit message:

Author:     djm at openbsd.org <djm at openbsd.org>
AuthorDate: Wed Sep 8 23:31:39 2021 +0000
Commit:     Damien Miller <djm at mindrot.org>
CommitDate: Thu Sep 9 12:35:37 2021 +1000

    upstream: Use the SFTP protocol by default. The original scp/rcp

    protocol remains available via the -O flag.

    Note that ~user/ prefixed paths in SFTP mode require a protocol extension
    that was first shipped in OpenSSH 8.7.

    ok deraadt, after baking in snaps for a while without incident

> The notice includes a command to run to determine if a server will be
> affected by this issue - I would appreciate it if folks can try it
> with servers they use and report back, to help determine if this will
> be an issue in practice and to help guide the next base system update.

I'm not exactly sure what you are expecting as a report. I still have some
very old keys that use
ssh-rsa. I've noticed this on an OpenBSD -snapshot test vm, as i was unable
to
connect.
So, yes, I will be affected, if I do not replace my old keys by then.

<ot> which then probably is a good opportunity to organise my keys and not
have like
200 different keys :) </ot>


Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20210911/b4cb52ff/attachment.sig>

10.09.2021 1:01, Ed Maste wrote:
> 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
> 
> If the host key verification fails and no other supported host key
> types are available, the server software on that host should be
> upgraded.
I have some telco equipment (E1/SS7) based on custom Linux distro built by a
vendor:

$ ssh -oHostKeyAlgorithms=-ssh-rsa user at host
Unable to negotiate with X.X.X.X port 22: no matching host key type found. Their
offer: ssh-rsa

I've already asked the vendor for possible upgrade and was told that no
upgrade will be available.

Will I be able to use ssh_config and following command to re-enable the feature
after planned import?

HostKeyAlgorithms ssh-rsa

> 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