28

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.

Community
  • 1
John
  • 1,009
  • 3
  • 11
  • 16
  • 1
    Been a while, but worth mentioning, the server *can* however, narrow down the possiblities and can indeed choose a required cipher by defining only one, e.g. chacha20-poly1305@openssh.com. This would force the client to use that cipher to connect ,p – Njomsky Feb 02 '15 at 04:54

3 Answers3

32

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.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 5
    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
  • Regarding HMAC/MD5, if you knew what the packet was going to look like (your attack payload was static and not dynamic), you could generate this packet well in advance. It would not need to be generated on the fly. I agree that it'd be difficult, and I think this is just a second layer, but I think it may be reasonably practical to use a precomputed collision in MD5 here. The function is : mac = MAC(key, sequence_number || unencrypted_packet) Thoughts? – Alex Lauerman Apr 29 '14 at 18:48
  • 1
    The function is MAC(...), not MD5(...). MD5 collisions do not translate into HMAC collisions. Refer to [RFC 2014](http://tools.ietf.org/html/rfc2104) for a description of how HMAC works. – Tom Leek Apr 29 '14 at 18:52
  • Any chance the situation has changed since you wrote this in 2013? – pioto Nov 17 '15 at 04:09
  • 1
    @pioto: not to my knowledge. There is still no known attack that would apply to a SSH connection. OpenSSH's defaults may have changed, though, because they must not only choose only secure algorithm, but they must also contend with the feelings of their user base, which are notoriously subject to drift over times. – Tom Leek Nov 17 '15 at 13:19
  • @TomLeek, does the [SLOTH](http://www.mitls.org/pages/attacks/SLOTH) attack change this? – sampablokuper Jan 09 '16 at 07:44
  • A good reason to use CTR over CBC is **speed!** AES256 is slower than AES192 which is slower than AES128 but when probably implemented, CTR is always much faster than CBC (AES192-CTR is faster than AES128-CBC). See here: https://www.cryptopp.com/benchmarks.html And as CTR is no way less secure than CBC, there is a good reason to use CTR as SSH is also used by `scp` and by `rsync` and when copying large files, *speed does matter!* – Mecki Mar 11 '16 at 00:25
  • @Mecki: I would contend that speed matters only up to what the underlying network can absorb. Even with CBC, a normal PC can do AES encryption faster than what can be sent over gigabit ethernet -- especially since all modern x86 systems have the AES-NI opcodes. What CTR parallelism gains is better performance for constant-time implementations (not table-based implementations) on platforms that have large integer registers but do not have dedicated AES hardware -- there we are talking about smallish ARM systems, not PC. – Tom Leek Mar 11 '16 at 13:58
  • @TomLeek An Intel Core 2 1.83 GHz reaches processing limit at 80 MiB/s when using AES256-CBC. This may be quite okay to saturate most networks link easily, but a lot of servers out there have much less raw CPU power than that (some don't even have 25% of that performance, especially VPS and virtual cloud servers) and the server may need also some CPU time for other tasks than your file copy, don't you think? And I often use SSH to copy between two servers with switched GBit link and SSDs and trust me, encryption will have an impact here on the services running on these servers during copy. – Mecki Mar 11 '16 at 14:10
  • Fast forward one year later, OpenSSH has [removed CBC ciphers](https://www.openssh.com/txt/release-6.7 "OpenSSH 6.7 was released on 2014-10-06") in OpenSSH 6.7 (10/2014) in their default configuration and then disabled them along with MD5-based and truncated HMAC algorithms in [OpenSSH 7.2](https://www.openssh.com/txt/release-7.2 "OpenSSH 7.2 was released on 2016-02-29") (02/2016). – ckujau Dec 07 '19 at 04:14
10

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 hmac-md5-etm@openssh.com, 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.

Mecki
  • 481
  • 4
  • 8
2

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

Srikant Mohapatro
  • 21
  • 1