Applied-Crypto-Hardening project and new cyphers. #28
Comments
|
Thanks @ypid, I didn't know this project before. Applied crypto hardening (ahc) uses different algorithms, depending on the openSSH-version in use: 6.0 6.5 6.6 Here's what we are using:
Here are the differences (
I did not compare the Ubuntu 12.04 and EL6 because they use a OpenSSH version < 6, which is not even supported by ahc.
You're right, but I don't know why. I also couldn't find any information, why they're using these settings. @chris-rock, what do you make of this? Do you see any problems/improvements? |
|
You might also want to checkout debops.sshd which I use to configure sshd. The latest update solves this issue by allowing a OpenSSH version specific configuration. |
|
Refactoring the role to use the ciphers, macs and kexs according to the used openssh-versio seems like a better alternative then using operating-system dependant settings. |
|
@rndmh3ro Any progress here? I'm noticing that the Debian 8 settings unnecessarily remove ciphers such as Note that you can query the supported options directly from ssh, rather than inferring from the version: Which might provide a path for better validation of the options. Happy to provide more info if useful, but in the near-term I'll probably just submit a PR that preserves the already supported modern ciphers under Debian 8. |
|
Thanks, @conorsch, I didn't know that you could do this with ssh. I'll take a look how this can help us in this role! |
|
just a remark - disabling KEX diffie-hellman-group14-sha1 server-side makes it impossible for me to connect to the server with an debian client. The client side settings are the default one from the openssh package (cipher/kex etc. not specified in config file) client: Debian GNU/Linux 8.5 (jessie) with openssh-client 1:6.7p1-5+deb8u2 For ciphers and MACs the strong/default 66er version work fine. |
|
cc @atomic111 |
|
@sseide i will take a look and come back to you in the next days |
|
@sseide yes we disabled the KEX diffie-hellman-group14-sha1 in the default hardening configuration, but you have still the option to enable the wek Kex with You can find some information about the issue here https://blog.gdssecurity.com/labs/2015/8/3/ssh-weak-diffie-hellman-group-identification-tool.html and http://www.heise.de/forum/heise-Security/News-Kommentare/Logjam-Attacke-Verschluesselung-von-zehntausenden-Servern-gefaehrdet/Re-Haerten-von-SSH/posting-7888602/show/ Debian 8 (OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015) is supporting the better kex: ` diffie-hellman-group1-sha1 so it should work. if i am wrong then please let me know |
|
FWIW, |
|
Sorry for the long time. I check again trying to recreate the issue - here is a step-by-step guide to reproduce the "problem" of Debian stable unable to connect after strong crypto applied: ssh-client$ lsb_release -irc Distributor ID: Debian Release: 8.5 Codename: jessie ssh-client$ dpkg -s openssh-server | grep Version Version: 1:6.7p1-5+deb8u3 ssh-client$ dpkg -s openssh-client | grep Version Version: 1:6.7p1-5+deb8u3 ssh-client$ ssh -Q kex diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 diffie-hellman-group-exchange-sha1 diffie-hellman-group-exchange-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group1-sha1 curve25519-sha256@libssh.org` Now i create a new VM with debian 8.5 with up-to-date pachtes via Vagrant as the ssh server ssh-client$ vagrant init debian/contrib-jessie64 ssh-client$ vagrant up ssh-client$ vagrant ssh vagrant@contrib-jessie:~$ sudo apt-get update && sudo apt-get upgrade vagrant@contrib-jessie:~$ lsb_release -irc Distributor ID: Debian Release: 8.5 Codename: jessie vagrant@contrib-jessie:~$ dpkg -s openssh-server | grep Version Version: 1:6.7p1-5+deb8u3 vagrant@contrib-jessie:~$ ssh -Q kex diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 diffie-hellman-group-exchange-sha1 diffie-hellman-group-exchange-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group1-sha1 curve25519-sha256@libssh.org now i run your ansible playbook with default values - as OpenSSH is new enough only vagrant@contrib-jessie:~$ sudo cat /etc/ssh/sshd_config ... # Cryptography # ------------ # **Ciphers** -- If your clients don't support CTR (eg older versions), cbc will be added # CBC: is true if you want to connect with OpenSSL-base libraries # eg ruby Net::SSH::Transport::CipherFactory requires cbc-versions of the given openssh ciphers to work # -- see: (http://net-ssh.github.com/net-ssh/classes/Net/SSH/Transport/CipherFactory.html) # Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr # **Hash algorithms** -- Make sure not to use SHA1 for hashing, unless it is really necessary. # Weak HMAC is sometimes required if older package versions are used # eg Ruby's Net::SSH at around 2.2.* doesn't support sha2 for hmac, so this will have to be set true in this case. # MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 # Alternative setting, if OpenSSH version is below v5.9 #MACs hmac-ripemd160 # **Key Exchange Algorithms** -- Make sure not to use SHA1 for kex, unless it is really necessary # Weak kex is sometimes required if older package versions are used # eg ruby's Net::SSH at around 2.2.* doesn't support sha2 for kex, so this will have to be set true in this case. # based on: https://bettercrypto.org/static/applied-crypto-hardening.pdf KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 ... Now trying to connect via ssh from the host/client i cannot login anymore: ssh-client$ ssh -p 2202 -i private_key vagrant@localhost Unable to negotiate a key exchange method Disabling on the ssh server the Line with "KexAlgorithms" and restarting the ssh server i can login again... ssh-client$ ssh -p 2202 -i private_key vagrant@localhost vagrant@contrib-jessie:~$ On debian i must use the playbook variable |
|
@conorsch - do you tested the 3.0 release? This version does not know Debian - it only checks for Ubuntu for strong crypto. Only the latest version from github or the new 3.1 checks for Debian and applies the same settings as for newer Ubuntu versions (without the |
That's not entirely true. While there's no separate check for debian 8, the However I just tested Debian 8 with release 3.0 and 3.1 and with the default settings on Docker and vagrant (same box as yours). It worked all the time. I'm really not sure why it does not work for you. Maybe its a problem with the ssh client? |
|
@sseide Disregard my "testing" mentioned earlier—the Debian clients I used for testing are running Stretch, not Jessie. SSH client version: Which is clearly more recent than Jessie: I'll try to reproduce your problem with Jessie-to-Jessie connections. |
|
@rndmh3ro Checked the thing on another PC and wasnt able to reproduce there either. @conorsch - no further test needed as working now. Thanks for pointing out my problem with the client config... |
|
@sseide Roger that, thanks for saving me the time! |
|
I'm going to close this ticket now. If anyone thinks, we should use other/more ciphers, please open up a issue here: https://github.com/dev-sec/tests-ssh-hardening, since this is where the ciphers are defined. This ansible role simply adopts them. |
Do you know the Applied-Crypto-Hardening project?
One thing I noticed is that this role actually disables strong cyphers like aes256-gcm@openssh.com which are available in newer versions.
https://github.com/BetterCrypto/Applied-Crypto-Hardening/tree/master/src/configuration/SSH/OpenSSH
The text was updated successfully, but these errors were encountered: