openssh unix dev - Oct 2021 - OpenSSH with OpenSSL 3.0: preventing loss of remote access

Hello,

TL;DR. Bad openssl config can break remote access to the system via SSH.

OpenSSL 3.0 doesn't provide any crypto primitives itself. It is done via
the providers' mechanism. The provider should be loaded and activated to
make some algorithms and RNG available.

The default provider is a bit special. If no providers are activated
explicitly, the default one is activated implicitly. (See details in
https://github.com/openssl/openssl/issues/16249). Its activation is
commented out in the config file. If anybody tries to activate a legacy
provider and doesn't uncomment the default provider activation, the system
becomes almost unsuitable for work and not remotely accessible anymore.

I am pretty sure that there will be enough people who because either not
reading the documentation or just being in a hurry will turn the remote
accessibility off.

To prevent it, the viable option is explicitly load the default provider in
openssh if necessary.
We can check if it is necessary in several ways. First, we can check if the
default or FIPS provider is already loaded. Second, we could check that any
algorithm (I'd prefer some of the AES-CTR family) is available, and load
the default provider if not, implying that it the selected algorithm is
implemented in the provider carrying also some sort of key exchange
algorithm, RNG, etc. I have a tentative patch for this purpose.

There also may be an option to add an explicit switch
'FallbackToDefaultProvider yes' to the openssh configuration.

Please, any feedback is welcome.

-- 
Dmitry Belyavskiy

On 04.10.21 10:57, Dmitry Belyavskiy wrote:
> OpenSSL 3.0 doesn't provide any crypto primitives itself. It is done
via
> the providers' mechanism. The provider should be loaded and activated
to
> make some algorithms and RNG available.
> 
> The default provider is a bit special. If no providers are activated
> explicitly, the default one is activated implicitly. (See details in
> https://github.com/openssl/openssl/issues/16249). Its activation is
> commented out in the config file. If anybody tries to activate a legacy
> provider and doesn't uncomment the default provider activation, the
system
> becomes almost unsuitable for work and not remotely accessible anymore.
> 
> I am pretty sure that there will be enough people who because either not
> reading the documentation or just being in a hurry will turn the remote
> accessibility off.
> 
> To prevent it, the viable option is explicitly load the default provider in
> openssh if necessary.
> We can check if it is necessary in several ways. First, we can check if the
> default or FIPS provider is already loaded. Second, we could check that any
> algorithm (I'd prefer some of the AES-CTR family) is available, and
load
> the default provider if not, implying that it the selected algorithm is
> implemented in the provider carrying also some sort of key exchange
> algorithm, RNG, etc. I have a tentative patch for this purpose.
> 
> There also may be an option to add an explicit switch
> 'FallbackToDefaultProvider yes' to the openssh configuration.
> 
> Please, any feedback is welcome.
My .02: There is a *lot* of ways to hose one's SSH access, from various 
statements in the /etc/ssh/ config files, to peripheral config files 
(oops, chmod -R 660 got ~/.ssh/authorized_keys, too), to the local OS 
(iptables) and beyond. For a great many environments, the last resort is 
access to a login prompt (where you can use a password) through some OOB 
management solution (physical access, iLO, dialin modem, your cloud 
provider's admin WebUI, whatever). OpenSSH *cannot* cover as many 
scenarios, much less all, and I doubt that it should insinuate that it 
wants to.

Apart from that, any algorithm nominated as a trigger for such an 
autocompletion would gain implicit tenure, making it difficult to phase 
it out when necessary (cryptographically broken). Note how little 
overlap current-day OpenSSH setups have with the set of algos listed in 
the original RFCs it *otherwise* still adheres to ...

More generally speaking, a rule along the lines of "unless you have 
available at least a) one symmetric cipher of >= 256 bit, b) one 
asymmetric cipher as strong as 4 kbit RSA, c) a hash function of >= 256 
bit, ..., the default provider will be loaded as well" seems sensible, 
but it would need to replace the "unless you have ANYTHING" rule
within
OpenSSL 3, rather than being a fix by the application on top.

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20211005/895f910f/attachment.p7s>