Secure Configuration of Ciphers/MACs/Kex available in SSH

Question

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,[email protected],[email protected],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,[email protected],[email protected],arcfour256

Next, for the HMAC, it supports the following:

[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96

And I was looking at changing it to this:

[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected],hmac-sha1,[email protected],[email protected],[email protected],[email protected],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.

Answer 1

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.

Answer 2

Everyone who is really worried about security of SSH probably wants to read this page:

https://stribika.github.io/2015/01/04/secure-secure-shell.html

It goes through all key exchanges, server authentications, ciphers and MACs that OpenSSH supports and then throws out whatever cannot really be considered secure anymore, giving valid justification for everything it eliminates. With this setup, you are rock solid!

TL;DR? The winners for highest security are:

Key Exchange: curve25519-sha256
(fallback: diffie-hellman-group-exchange-sha256)

Server Authentication: Ed25519 with SHA512
(fallback: RSA with SHA1 4096 Bits)

Cipher: chacha20-poly1305
(fallback: aes256-ctr)

MAC: hmac-sha2-512-etm
(fallback: hmac-sha2-512)

Fallback is what you will find on most SSH servers, not quite as secure, but still secure enough by today's standards.

Just one comment from my side: If you use SSH also for copying data (scp or rsync) or for port forwarding X11 or VNC, performance and latency are not irrelevant. In that case, aes128-ctr will offer best performance (out of the ciphers that are known to be secure as of today) and you may consider using [email protected], as even MD5 has been broken, HMAC-MD5 hasn't up to today and MD5 beats SHA-1 in speed and SHA-2 even by far. To get an idea for algorithm speeds, see that page:

https://www.cryptopp.com/benchmarks.html

IMHO it's an acceptable trade off: trading some security for a lot more speed.

What about chacha20-poly1305? I neither have benchmarks for chacha20-poly1305 so far, nor can I say it's proven to be secure. It's supposed to be a replacement for RC4 (aka arcfour), so it's probably even faster than aes128-ctr in software, yet modern Intel CPUs can calculate AES128 in hardware, so if your SSH implementation makes use of that, you can expect AES128 to be very fast. Still ChaCha may be faster but it's the not yet proven security that worries me a bit; too little attacks have been tried on it and even though it exists since 2008, only recently ChaCha has become popular when it was revealed that the NSA can break RC4 SSL/TLS connections in realtime. ChaCha shall fix that and replace RC4 in TLS but that's no proof for its security.

Don't ever worry about key exchange or server authentication, their speed only play a role at the initial connect and whenever the key needs to be renewed (when that happens depends on the chosen cipher and how much data you transfer... every cipher has a data limit and once that is reached, a new key is exchanged as staying with the existing one would weaken the encryption from that point on), but renews don't happen that frequently, so for these two I'd always go for highest security and ignore speed altogether.

And never use the truncated hashes (-96) for MD5 or SHA-1. They give you no real benefit other than saving a couple of bytes per packet (4 for MD5, 8 for SHA-1). The hash will take equally long to calculate/verify (no speed benefit) and the truncation only weakens the security (no security benefit). Truncation would pay off for SHA-2 as these are much larger (32, 48, 64 bytes per packet) and such large hashes makes no sense considering the maximum size of a transmission packet, but for these truncation is not an option.

Answer 3

In order to remove the cbc ciphers, Add or modify the "Ciphers" line in /etc/ssh/sshd_config as below: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,arcfour

In order to remove HMAC MD5 Add or modify the MACs line in /etc/ssh/sshd_config as below : MACs hmac-sha1,hmac-ripemd160

Restart SSHD to apply the changes: service sshd restart