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
Comments
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. |
Would you mind compiling a list of weak algorithms you would want to us to display a warning. |
Such as |
Add callback in 54681ecf5090d6e84fcc4e5b3088fd9944310426. |
Replying to [comment:4 dkocher]:
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? |
Current supported algorithms in default configuration:
|
Replying to [comment:4 dkocher]:
This is just an example of negotiated algorithms. |
Sorry, I was pretty busy, but here my list. I am not completly familiar with the notation, I hope I got it right.
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 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. |
The current default setting for these preferences is empty. |
Sample message with |
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
Screen Shot 2015-02-17 at 15.46.35.png
(70.7 KiB)The text was updated successfully, but these errors were encountered: