Add Client Audit warning for poor algorithm order

[severach]

Since the client order determines what is selected, for the client audit add a warning on poor order. For JSCH-0.1.54

JSCH Client server hostkey algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

ssh-dss should not be before ecdsa?

JSCH Client-to-server encryption algorithms: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc

128 should not be before 192 and 256? 3des should not be before aes192.

JSCH Client-to-server MAC algorithms: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96

md5 should not be before sha1 which should not be before sha2.

It's not just JSCH. Every client has at least some nonsensical orders. Server side wouldn't need to be so aggressive about deprecating insecures if clients didn't have such broken default order.

Some accommodation should be made for low power clients that intentionally list lower algorithms first.

[egberts]

after culling for obsolete algos, then any mis-ordering of algo strength should be at worse a yellow alert. its hard to qualify strength between some algos. the easy algos ones should be in bit-strength, but dont try to compare bit against ECs.

[thecliguy]

@severach A policy audit might provide the functionality you seek...

• Configure your SSH client so it is adheres to your security requirements.
• Build a policy file modeled on your client as the exemplar:
  • ssh-audit -c 127.0.0.1 --make-policy=MyPerfectClientPolicy.txt
  • Using your SSH client, connect to 127.0.0.1 on port 2222.
• Scan your client using the policy file:
  • ssh-audit -c 127.0.0.1 --policy=MyPerfectClientPolicy.txt
  • Using your SSH client, connect to 127.0.0.1 on port 2222.

If the order of any algorithms does not exactly match what's defined in the policy file then a policy audit will fail advising of such.

[jtesta]

@severach : as @thecliguy mentioned, you can perform your own hardening of a client or server, then create a custom policy to validate against it.

ssh-dss should not be before ecdsa?

ssh-dss uses a 1024-bit modulus, which is weak. ECDSA uses the NIST P-curves, which are suspected of being back-doored by the NSA. I'd recommend disabling both of those entirely.

128 should not be before 192 and 256? 3des should not be before aes192.

The order between 128, 192, and 256-bit ciphers is not so important for most use cases; they're all strong. High-security applications that don't mind a little more overhead should order them as 256, 192, then 128. Or perhaps disable all except 256.

3des is a deprecated and broken cipher. It should always be disabled.

md5 should not be before sha1 which should not be before sha2

MD5 and SHA-1 are both broken, and should never be used.