3

I specify "Putty" as otherwise I feel the question would be too broad.

What are the algorithm (as of March 2016) that one needs to be warned about (ie, those that no longer are considered safe enough) when logging on a ssh server...

For Putty, I want to talk about the "SSH" and "SSH-Kex" sections of the config, ie the Encryption Cipher and the Key exchange algorithms. (and any other relevant config you may want to add)

Common choices for "SSH" "Encryption cipher selection policy" :

AES (SSH-2 only)
Blowfish
3DES
Arcfour (SSH-2 only)
DES

And for SSH - Kex (Key Exchange)

Diffie-Hellman group exchange
Diffie-Hellman group 14
Diffie-Hellman group 1
RSA-based key exchange

Putty allows one to move a "warn below here" setting, but I wonder where to place it at nowadays... Pointers welcomed!

A simple search was not enough for me... And we could also date each answer to ensure they give an hint as to their relevance [and [any?]one could then update them when things change, to keep the info as current as possible]

5

In SSH, for all algorithm classes (encryption, MAC, key exchange and public-key authentication), the client and the server send to each other their lists of supported algorithms; the client lists are ordered by preference, and that preference is honoured: the protocol is such defined that the chosen algorithms will be the first in each client list that also appears in the corresponding server list.

I recall that point because it highlights what this "warn below here" option really means. It means that there are some algorithms that the human user would really prefer not to use -- but, for some reason, he included them in its list of supported algorithms. So what will the human user actually do if he gets the warning ? Will he click on "OK, I got it" and proceed with the connection ? Or will he bail out ? In the first case, the algorithms are thus functionally supported, while in the second they are not. Does it really make sense to have a warning popup under these conditions ? If the user does nothing else about the warning than deciding whether to keep connecting or abort, then the warning is meaningless; it would be simpler and safer to simply omit from the list all algorithms that the user is not ready to use.

The warning is useful when the user (on the client side) can, at some point, alter the configuration of the server. It can then serve as a indicator for a misconfigured server, that the user may then fix himself at a later point.


All of that being said, there are reasons why some algorithms are preferable to others. In no particular order:

  • Protocol version should be SSH2 only. SSH1 has flaws, and if the server you are trying to talk to supports only SSH1 then it is very old software which is probably riddled with unfixed but known vulnerabilities, so you do not really want to connect to that server at all.

  • DES uses a 56-bit key (officially 64 bits, but 8 bits are ignored in the process, so effectively 56 bits). This is in range of exhaustive search by attackers with a bit of budget (in the thousands of dollars, not in the millions) so you really want to avoid that.

  • RC4 has known biases. SSH can support some variants that discard the first 1536 bytes of RC4 output, which removes the biggest biases, but not all. While there not has been any published practical exploitation of RC4 biases in the context of SSH yet, this is still a worry and it is recommended not to use RC4.

  • Blowfish and 3DES are 64-bit block ciphers. In SSH, they are used in CBC mode, which means that they begin to run into trouble after encrypting about 232 blocks (of 8 bytes each), i.e. about 32 gigabytes. If you occasionally transfer gigabytes of data over a single connection, then you will want to avoid 64-bit block ciphers, and concentrate on 128-bit block ciphers like AES.

  • 3DES is slow in software. This may matter if you have a fast network (gigabit ethernet) or very slow hardware (not a PC).

  • If you have the choice, prefer "modern" encryption modes like GCM or CTR instead of CBC. The mode describes how the block cipher will be used.

  • For key exchange, you may want to avoid the "group 1" which uses a 1024-bit modulus. Breaking Diffie-Hellman modulo a 1024-bit prime has never been done in a public demonstration (current record is a 596-bit modulus) but it is within technological reach of mankind (projected budget would then be in the dozens or hundreds of millions of dollars). The "group 14" is a 2048-bit modulus, which is fine.

  • "Diffie-Hellman group exchange" is DH in server-chosen parameters, and normal servers will take care to select parameters that at least match the strength of their authentication public key. So this is safe as long as the server (or its administrator) does not do anything stupid.

  • RSA key exchange is pretty rare, because it involves generating an ephemeral RSA key pair on the server side, which is relatively expensive. Usual servers do not do that.


So my advice would be: remove all symmetric ciphers that are not AES; keep only DH group 14 and the "DH group exchange"; don't bother with the "warn me" limit; instead, use the failure to connect as a warning. If you cannot connect to a given server with sane parameters, then something is amiss and you should pause and think -- a forced abort is more likely to make you think than a simple warning popup. Maybe the lack of AES support for a given server is normal, but this requires an explicit decision, not a popup that is to easy to ignore.

  • Thanks, nice answer (as you always do !). Maybe just add a "as of yyyy-mm-dd", to indicate the date at which you were aware of the accuracy of the answer? [which can't be the last edit time, as that one could be just for typos, etc]. That way in a few weeks this may get revised when further breakthrough occurs and render some of the still-ok settings obsolete? [quantum computer, anyone? ^^ or maybe some kind of DNN's side effect]. And while I agree that removing the bad settings is best, I also focus admins [who still need to connect & correct, and should pay attention to the warning] – Olivier Dulac Mar 9 '16 at 14:30
  • Quote: If you have the choice, prefer "modern" encryption modes like GCM or CTR instead of CBC. The mode describes how the block cipher will be used. Unquote. May I have your expertise to advise whether or not the CTR is supported in Putty? If so, which encryption mode should be chosen that is as same as CTR? – Jack Feb 16 '17 at 7:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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