Add ability to deactivate weak crypto, SHA-1, DES etc.

[lbort]

I think the logical consequence of tickets #8488 and #8528 would be to offer the users the possibility to choose which Algorithms Cyberduck may use. This would include all the three parts described in the (really nice) blogentry mentioned in #8488, key exchange, symetric ciphers and Message Authentication Codes.

Servers that I control will not offer weak crypto anymore as soon as cyberduck offers something better, since it is the only software I use which still needs that. But when connecting to other servers, I would like be able to keep cyberduck from using the weak algorithms and display an error message just like described in the tickets mentioned above, if it cannot find a match. In case the server in question really only offers those protocols, one still can reactivate something that matches if one really wants to connect. But without that possibility to deactivate weak crypto, Cyberduck is not 100% safe, even if the stronger algorithms are incorporated.

This choice should be accessible in the SFTP-Settings imho, but if this is not a priority after adding the new algorithms, I would also be happy to delete some of them from the line in the configfile similar to .ssh/config, if something like this exists in the cyperduck.app contents.

[dkocher]

We might want to add a callback for negotiated algorithms and let the user choose to continue for weak ciphers as the insecure connection warning when connection to a FTP server with no TLS.

[dkocher]

Would you mind compiling a list of weak algorithms you would want to us to display a warning.

[dkocher]

Such as [ kex=diffie-hellman-group14-sha1; sig=ecdsa-sha2-nistp256; c2sCipher=aes128-ctr; s2cCipher=aes128-ctr; c2sMAC=hmac-sha1; s2cMAC=hmac-sha1; c2sComp=zlib@openssh.com; s2cComp=zlib@openssh.com ].

[dkocher]

Add callback in ​54681ecf5090d6e84fcc4e5b3088fd9944310426.

[dkocher]

Integrated in r16669.

[lbort]

Replying to dkocher:

Such as [ kex=diffie-hellman-group14-sha1; sig=ecdsa-sha2-nistp256; c2sCipher=aes128-ctr; s2cCipher=aes128-ctr; c2sMAC=hmac-sha1; s2cMAC=hmac-sha1; c2sComp=zlib@openssh.com; s2cComp=zlib@openssh.com ].

Sure, I can provide a list like that, but for that it would be good to have a complete list of all supported algorithms. Otherwise my list might be incomplete or list something that is not supported anyway.

So, is the quote above just an example, or are these all (currently) supported algorithms?

[dkocher]

Current supported algorithms in default configuration:

• Key exchange. diffie-hellman-group14-sha1 and diffie-hellman-group1-sha1.
• Ciphers. aes128-cbc, aes128-ctr, aes192-cbc, aes192-ctr, aes256-cbc, aes256-ctr, blowfish-cbc, 3des-cbc.
• MAC. hmac-md5, hmac-md5-96, hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512
• Signatures. SHA1withDSA, SHA256withECDSA, SHA1withRSA

[dkocher]

Replying to dkocher:

Such as [ kex=diffie-hellman-group14-sha1; sig=ecdsa-sha2-nistp256; c2sCipher=aes128-ctr; s2cCipher=aes128-ctr; c2sMAC=hmac-sha1; s2cMAC=hmac-sha1; c2sComp=zlib@openssh.com; s2cComp=zlib@openssh.com ].

This is just an example of negotiated algorithms.

[lbort]

Sorry, I was pretty busy, but here my list. I am not completly familiar with the notation, I hope I got it right.

[kex=diffie-hellman-group14-sha1; kex=diffie-hellman-group1-sha; c2sCipher=aes128-cbc; c2sCipher=aes192-cbc; c2sCipher=aes256-cbc; c2sCipher=blowfish-cbc; c2sCipher=3des-cbc; c2sMAC=hmac-md5; c2sMAC=hmac-md5-96; c2sMAC=hmac-sha1; c2sMAC=hmac-sha1-96; s2cCipher=aes128-cbc; s2cCipher=aes192-cbc; s2cCipher=aes256-cbc; s2cCipher=blowfish-cbc; s2cCipher=3des-cbc; s2cMAC=hmac-md5; s2cMAC=hmac-md5-96; s2cMAC=hmac-sha1; s2cMAC=hmac-sha1-96; sig=SHA1withDSA; sig=SHA256withECDSA ]

This is a quite long list, but all of the above are either using broken algorithms like MD5 and SHA-1, or too short keys like DSA, or rely on NIST curves, which can't be trusted either. I am not entirely sure about the aes-cbc ciphers, but I assume they are also vulnerable. I didn't read everything, but for some info about that, see ​http://www.openssh.com/txt/cbc.adv and ​http://homes.cs.washington.edu/~yoshi/papers/TISSEC04/

The list includes all currently supported kex-algorithms, so at least one of the suggested kex-algorithms needs to be implemented before activating the warning, otherwise it will always pop up. I also suggest putting the stronger ciphers with the longer keys first in the list of all available algorithms, since apparently the client chooses the first one in his list that is also supported by the server. In the long run, some more algorithms might be nice for the other part besides key-exchange, to be as compatible and secure as possible.

[dkocher]

Added properties to override algorithms that should yield a warning.

ssh.algorithm.cipher.blacklist
ssh.algorithm.mac.blacklist
ssh.algorithm.kex.blacklist
ssh.algorithm.signature.blacklist

in r16820.

[dkocher]

The current default setting for these preferences is empty.

[dkocher]

Sample message with ssh.algorithm.kex.blacklist set to diffie-hellman-group14-sha1 diffie-hellman-group1-sha.