Why let openSSH get away with unsafe fallbacks

[ecki]

As reported in #206 OpenSShd has a rather insecure fallback and makes it nearly impossible to turn it off.

imho ssh-audit should not hide this finding but call openssh out on it.

This is also a problem for people who want to implement a strong crypto policy with the RH framework but miss the fact that this does not disable this parameters (unless you specify it correctly)

[thecliguy]

@jtesta - Apologies for dropping the ball with #206 and leaving it hanging. The last 12 months has been hectic for me.

Your justification in #206 is that it's OK to sheild users of OpenSSH from a fail because there are no hardening steps they can perform (due to questionable design in OpenSSH) and the likelihood of 1024/1024/2048 being negotiated is minimal.

I can't think of a solid example right now, but I've encountered systems featuring an SFTP component as a means of getting data in and out, and user configurable security settings were practically non-existent. So you were pretty much stuck with whatever the settings were that the dev compiled with. Let's suppose such a system acts in an SFTP server capacity and supports three host key algorithms - ssh-rsa, rsa-sha2-256 and rsa-sha2-512. Now let's extend your logic for #206 to this situation... The presence of ssh-rsa would normally result in a fail by ssh-audit, but the admin of this system can't switch it off, so should we not make an exemption because there are no possible hardening steps to perform. And there's no harm right, because only a really old client would try to negotiate ssh-rsa.

Well... Of course I don't beleive ssh-audit should do that. It should do exactly what it's currenly doing, telling the user the truth so they can make a decision whether to accept the shortcomings of the software, or to switch to an alternative. And I think that's exactly the approach that should be taken with OpenSSH regarding #206, giving the users the truth and letting them decide whether to:

• A. Continue using OpenSSH with DH GX enabled and accept the risk.
• B. Continue using OpenSSH with DH GX disabled to completely mitigate the risk.
• C. Abandon OpenSSH and find an alternative.

[jtesta]

imho ssh-audit should not hide this finding but call openssh out on it.

@ecki: Currently, ssh-audit reports the following:

(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
                                                      `- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).

So the user is already alerted about this situation, though this does not result in a warning nor failure. How would you prefer ssh-audit react instead?

And I think that's exactly the approach that should be taken with OpenSSH regarding #206, giving the users the truth and letting them decide whether to:

@thecliguy: Could you more concretely describe what behavior you'd instead prefer from ssh-audit in this case? As shown above, ssh-audit does provide notes to the user, though it currently does not result in a warning nor failure.

[jtesta]

It seems that OpenSSH will be removing the DH fallback mechanism in the next release(!). I opened #310 to track this development and correctly handle the new version when it arrives.