Allow policies to pass if target host has stronger keys than required

[jtesta]

Currently, policies will fail if exact key sizes do not match (for example, if a policy states that 3072-bit host RSA keys are needed, but the host is using 4096, this causes a failure). Instead, a boolean flag in the policy file should dictate whether exact matches are needed, or if the host is allowed to have stronger keys. The default should be to allow stronger keys.

This will fix the problem where the hardening guides were written to use 3072-bit DH moduli (and larger), but the policies have been defined to require 4096 bits. This discrepancy was not found until the recent v3.0.0 release, which included a fix for OpenSSH's fallback mechanism.

Once this new functionality is implemented, the policies should be updated to require 3072-bit moduli or larger.

[thecliguy]

Does that mean the current expected value of 4096 in the built-in policies was a mistake, and it you actually intended it to be 3072?

[jtesta]

3072-bit Diffie-Hellman/RSA is equivalent to 128 bits of symmetric security. We're already flagging anything with that level (and above) as good, such as AES-128. Its inconsistent to treat 128-bit security as good for ciphers but insufficient for key exchanges and host keys.

By implementing a feature to allow targets to exceed the requirements, this lets us maintain 128-bit security without causing the users too much pain. Otherwise, we'd have to ask them to downgrade from 4096-bit DH/RSA to 3072 just to be rated as "in compliance."

[perkelix]

I'm really not convinced that lowering the minimum to 3072 is a good idea. Personally, I would stop recommending an algorithm that is know buggy on that specific SSH server implementation, both on the hardening website and in ssh-audit results.

[pepoluan]

Looking forward for the "minimum key strength" (rather than exact key strength) be implemented!

[jtesta]

Implemented in PR #242 and https://github.com/jtesta/ssh-audit/commit/9fae870260ee0067fd09840bc696b9459c4dba52.