The latest Maverick Legacy 1.7.27 releases include a new concept we have called Managed Security. This update introduces several changes under-the-hood to ensure that usage of the APIs maintains the highest possible security whenever possible.
We introduced a set of security levels to classify the algorithms we support. As a developer, you can now fix the minimum security level of your implementation to exclude algorithms according to your security policy.
We have also introduced a new chacha20poly1305 cipher and curve25519-sha256 key exchange to further extend the algorithms we support.
Configuring the security level
The security level can be configured globally for your JVM through the ComponentManager using the following code:
The available security levels are WEAK, STRONG, and PARANOID.
What does setting a minimum security level do in practice?
For both client and server APIs, when you set a minimum security level, all algorithms that are weaker than the level you have set will be removed and unavailable for use. The algorithms are also ordered based on our internal security score, which prefers the most secure algorithms first.
The default preferences have also now changed to match the most secure option.
Cipher: firstname.lastname@example.org HMAC: hmac-sha2-512 KEX: email@example.com Public Key: ssh-ed255219
Of course, any preference you currently set will override these new defaults.
Using a Managed Instance
With the client API, you now have the option to create a managed instance SshConnector. This option enables some new features to provide some resilience to key exchange and algorithm issues. If we detect a failure during the key exchange, the API will automatically exclude the problematic component and retry the connection with the next preferred algorithm.
To take advantage of this new feature, you must use the latest methods added in this release.
Unfortunately, this is not available for the server API because of the server’s relatively passive role in selecting algorithms for the connection. Algorithms are always selected based on the client’s preference.
When you use a managed instance, any preferences set in the SshContext will be ignored. It will always use the most secure algorithm as its first preference.
What security level should I use?
The changes we have made should ensure that the most secure algorithms are preferred. The security of a connection is only as strong as the algorithms that are supported by both parties. By setting our preferences based on security strength, we will select the most secure algorithms first with WEAK security used only as a last resort.
If ultimate compatibility with all clients and servers is required, you should (reluctantly) include WEAK security; however, with most modern SSH implementations, the STRONG level should provide a reasonable level of compatibility.
PARANOID provides the ultimate security level and, from my research, should undoubtedly work OpenSSH version 7.0 and upwards.
Below is the complete list of algorithms with their current order and security level. We have classified these based on several criteria; if you feel this any of these are wrong, then please get in contact.
Ciphers ---- PARANOID firstname.lastname@example.org email@example.com firstname.lastname@example.org STRONG aes256-ctr aes192-ctr aes128-ctr WEAK arcfour256 aes256-cbc 3des-cbc 3des-ctr aes192-cbc aes128-cbc blowfish-cbc arcfour128 arcfour Macs ---- PARANOID email@example.com hmac-sha2-512-96 hmac-sha2-512 STRONG firstname.lastname@example.org hmac-sha2-256 hmac-sha2-256-96 WEAK hmac-ripemd160 email@example.com hmac-sha1 hmac-md5 firstname.lastname@example.org email@example.com firstname.lastname@example.org hmac-md5-96 hmac-sha1-96 Public Keys ----------- PARANOID ssh-ed25519 STRONG rsa-sha2-512 rsa-sha2-256 x509v3-rsa2048-sha256 email@example.com firstname.lastname@example.org x509v3-ecdsa-sha2-nistp521 x509v3-ecdsa-sha2-nistp384 x509v3-ecdsa-sha2-nistp256 ecdsa-sha2-nistp521 ecdsa-sha2-nistp384 ecdsa-sha2-nistp256 email@example.com x509v3-ssh-rsa x509v3-sign-rsa-sha1 x509v3-sign-rsa ssh-rsa firstname.lastname@example.org WEAK x509v3-ssh-dss email@example.com ssh-dss x509v3-sign-dss Key Exchange ------------ PARANOID curve25519-sha256 firstname.lastname@example.org diffie-hellman-group18-sha512 diffie-hellman-group17-sha512 diffie-hellman-group16-sha512 diffie-hellman-group15-sha512 STRONG diffie-hellman-group14-sha256 diffie-hellman-group-exchange-sha256 rsa2048-sha256 ecdh-sha2-nistp521 ecdh-sha2-nistp384 ecdh-sha2-nistp256 WEAK rsa1024-sha1 diffie-hellman-group14-sha1 diffie-hellman-group-exchange-sha1 diffie-hellman-group1-sha1