Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
cyberduck opened this issue Feb 2, 2015 · 12 comments
Closed

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

cyberduck opened this issue Feb 2, 2015 · 12 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Feb 2, 2015

5586502 created the issue

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.


Attachments

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 3, 2015

@dkocher commented

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.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 3, 2015

@dkocher commented

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

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 3, 2015

@dkocher commented

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 ].

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 3, 2015

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 3, 2015

@dkocher commented

Integrated in b8a0919.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 3, 2015

5586502 commented

Replying to [comment:4 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?

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 3, 2015

@dkocher commented

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

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 3, 2015

@dkocher commented

Replying to [comment:4 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.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 6, 2015

5586502 commented

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.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 17, 2015

@dkocher commented

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 d90adf3.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 17, 2015

@dkocher commented

The current default setting for these preferences is empty.

Loading

@cyberduck cyberduck closed this Feb 17, 2015
@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Feb 17, 2015

@dkocher commented

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

Screen Shot 2015-02-17 at 15.46.35.png

Loading

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants