Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Following on the heels of the previously posted question here, Taxonomy of Ciphers/MACs/Kex available in SSH?, I need some help to obtain the following design goals:

  • Disable any 96-bit HMAC Algorithms.
  • Disable any MD5-based HMAC Algorithms.
  • Disable CBC Mode Ciphers and use CTR Mode Ciphers.

To this end, the following is the default list for supported ciphers:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour

I was looking at changing it to this:

Ciphers aes256-ctr,aes192-ctr,aes128-ctr,aes256-gcm@openssh.com,aes128-gcm@openssh.com,arcfour256

Next, for the HMAC, it supports the following:

hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96

And I was looking at changing it to this:

hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-sha1-etm@openssh.com,hmac-sha1,umac-128-etm@openssh.com,umac-64-etm@openssh.com,umac-128@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-ripemd160

Will this provide the most benefit in terms of security while mitigating the known weaknesses and attacks against common SSH configurations? Note that this question is not about 0-days or other related flaws in the SSH code and is specifically about the best possible arrangement and configuration of the ciphers, KexAlgorithms, and MACs. If the order is wrong, please suggest a better method to arrange them. This is also for the sshd_config file and not client connections.

share|improve this question
add comment

1 Answer

Right now, there is no known weakness with MD5 or CBC encryption or 96-bit MAC as they are used in SSH. So there is, stricto sensu, no security benefit in enacting the configuration modifications that your are proposing. It could be argued that removing support for some algorithms might lead to security issues because it may prevent some clients from connecting at all, thus forcing the user into finding workarounds which could be less secure (e.g. if scp is no longer possible, send the file over email...).

The least irrational of your design goals is the prohibition against CBC. CBC security requires proper management of Initialization Vectors; in the case of SSH, the IV is extracted from the last block of the previous packet (see the standard), which is fine as long as the attacker is not in a "chosen plaintext attack" situation. In practice, data which goes inside the SSH tunnel is not hostile, contrary to what occurs in HTTPS contexts where malicious client code (in Javascript) is a definite possibility. Similarly, padding oracle attacks on SSH are hard to leverage (assuming that the client or server code is not adequately protected), because SSH is connection oriented and won't (re)open failed connection automatically (there again, contrary to what happens with HTTPS).

Similarly, HMAC/MD5 is, as far as we know, as solid as ever. Known collision attacks on MD5 have no bearing on the security of HMAC, except in the fuzziest of senses (which can be summarized as: "MD5 stinks"). As for truncating HMAC values to 96 bits, there is again no reason to discriminate against that: an attacker will successfully bypass a 96-bit MAC value with probability 2-96, which is extremely low, and impossible to exploit in practice because any MAC failure on a single SSH connection is reported with a quite visible error message. This is again the way SSH is used which protects it against the level of attack automation that can be applied to HTTPS.

Therefore one could say that since pruning out algorithms from the list is for the benefit of your feelings of safety, the right list is the one which will make you feel safest. That's subjective, by definition, so you are the only one who can define this "best" list. As for me, I am quite happy with the defaults.


As for order, consider this excerpt from section 7.1 of RFC 4253:

  encryption_algorithms
     A name-list of acceptable symmetric encryption algorithms (also
     known as ciphers) in order of preference.  The chosen
     encryption algorithm to each direction MUST be the first
     algorithm on the client's name-list that is also on the
     server's name-list.

So the chosen algorithm will be the client's preferred algorithm. The server's order of preference is only a glorified comment; it won't impact which algorithm is actually chosen. Therefore, the order in /etc/sshd_config is not important.

share|improve this answer
2  
Thank you for the reply, links, and the good information. The driver for this question comes from a vulnerability scanning vendor and their recommendations. Those three design goals were suggested to reduce the risk score of the host while improving its security posture. –  John Jul 29 '13 at 18:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.