SSH Weak Ciphers

Home » CentOS » SSH Weak Ciphers
CentOS 17 Comments

Hi,

In a recent security review some systems I manage were flagged due to supporting “weak” ciphers, specifically the ones listed below. So first question is are people generally modifying the list of ciphers supported by the SSH client and sshd?

On CentOS 6 currently it looks like if I remove all the ciphers they are concerned about then I am left with Ciphers aes128-ctr,aes192-ctr,aes256-ctr for both /etc/ssh/sshd_config and
/etc/ssh/ssh_config. Is just using these three ciphers like to cause me any problems? Could having so few ciphers be creating a security concern itself?

Thanks

The following weak client-to-server encryption algorithms are supported by the remote service:
rijndael-cbc@lysator.liu.se arcfour256
arcfour128
aes256-cbc
3des-cbc aes192-cbc blowfish-cbc cast128-cbc arcfour aes128-cbc

The following weak server-to-client encryption algorithms are supported by the remote service:
rijndael-cbc@lysator.liu.se arcfour256
arcfour128
aes256-cbc
3des-cbc aes192-cbc blowfish-cbc cast128-cbc arcfour aes128-cbc

17 thoughts on - SSH Weak Ciphers

  • I suspect that “generally” people are not. I do, because I can, and so that I can offer at least some advice to people who aim to do so.

    If you’re going to go down this road, you should probably look at key exchanges and HMACs as well. On CentOS 7, I use:

    KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

    On CentOS 6, I believe you’d have to drop all of the @openssh.com items.

    I don’t think it’d be a security concern, just compatibility issues. So far, I’ve had minimal problems with restricted algorithms. I do have to make an exception for a slightly old WD MyBook World edition.

  • Am 19.10.2016 um 00:58 schrieb Gordon Messmer :

    Is there any command to find the supported list of KeyAlgos, MACs and Ciphers for the particular system (e.g. EL{5,6,7})? Similar to $ openssl ciphers -v …

  • The supported KexAlgorithms, Ciphers, and MACs are generally listed in the sshd_config man page. So ‘man sshd_config’ then look for the section of the item of interest.

    Erik

  • Once upon a time, Erik Laxdal said:

    Note that the man page does not always match the actual compiled binary
    (the build process does not update the man page to match configuration). The best way is to run “ssh -Q cipher” (as mentioned in the ssh_config and sshd_config man pages under Ciphers).

  • Hello Clint,

    Where did you get the idea that AES (~ Rijndael) is a weak cipher?

    RC4 (arcfour) is indeed considered insecure and Blowfish uses a block size that is too small for comfort. CAST-128 might still be quite usable and even though triple DES only provides about 80 bits of security it is still not considered broken.

    Regards, Leonard.

  • Am 19.10.2016 um 17:05 schrieb Chris Adams :

    That was my assumption.

    Great! For

    # SSH -V
    OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013

    # echo cipher cipher-auth mac kex key |xargs -n1 SSH -Q

    shows all informations.

    Unfortunately that applies only to EL7. ssh’s version of EL{5,6} doesn’t have the Q switch.

  • Hello Gordon,

    According to that document those issues are solved in the TLS 1.1
    specification. It also indicates that issues 1) and 2) do not exist in openssl since 0.9.6i and 0.9.6e respectively and that openssls TLS 1.0
    implementation handles padding correctly so issue 3) doesn’t exist in openssl either.

    However, I see that the openssh developers have decided to disable cbc algorithms in 6.7. Not sure what their rationale is as from the document you mention I grasp that these issues can be fixed by correctly padding the message and adding one extra random block before the message (“front padding”).

    Personally I would be more concerned whether or not to enable ECDSA
    algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).

    Regards, Leonard.

  • Morning Leonard,

    I believe the vulnerability scan was done using OpenVAS
    http://www.openvas.org/

    Medium (CVSS: 4.3)
    NVT: SSH Weak Encryption Algorithms Supported Summary The remote SSH server is configured to allow weak encryption algorithms. Vulnerability Detection Result The following weak client-to-server encryption algorithms are supported by the remote service:
    rijndael-cbc@lysator.liu.se arcfour256
    arcfour128
    aes256-cbc
    3des-cbc aes192-cbc blowfish-cbc cast128-cbc arcfour aes128-cbc The following weak server-to-client encryption algorithms are supported by the remote service:
    rijndael-cbc@lysator.liu.se arcfour256
    arcfour128
    aes256-cbc
    3des-cbc aes192-cbc blowfish-cbc cast128-cbc arcfour aes128-cbc

    Solution Disable the weak encryption algorithms. Vulnerability Insight The ‘arcfour‘ cipher is the Arcfour stream cipher with 128-bit keys. The Arcfour cipher is believed to be compatible with the RC4 cipher [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and should not be used anymore. The ‘none‘ algorithm specifies that no encryption is to be done. Note that this method provides no confidentiality protection, and it is NOT RECOMMENDED to use it. A vulnerability exists in SSH messages that employ CBC mode that may allow an attacker to recover plaintext from a block of ciphertext. Vulnerability Detection Method Check if remote SSH service supports Arcfour, none or CBC ciphers. Details:SSH Weak Encryption Algorithms Supported OID:1.3.6.1.4.1.25623.1.0.105611
    Version used: $Revision: 3160 $
    References Other:
    URL:https://tools.ietf.org/html/rfc4253#section-6.3
    URL:https://www.kb.cert.org/vuls/id/958563

    Thanks

    CentOS mailing list CentOS@CentOS.org https://lists.CentOS.org/mailman/listinfo/CentOS

  • *snip*

    For web server ECDSA certs is currently a concern because the only curves with popular support across browsers have parameters that were chosen for undocumented reasons.

    That doesn’t mean they are vulnerable but there is a question.

    OpenSSH uses Curve25519 for ECDSA which has documented reasons for the parameters chosen and thus are far less likely to be nefariously chosen.

    At least that’s my understanding of the situation, which could be flawed.

  • Allegedly they might.

    I use ecdsa certs on most of my websites, using secp384r1

    I formerly used secp521r1 but suddenly Google with no warning stopped supporting it in chrome. That company is too powerful.

    The only other option (that has both browser and CA support) is prime256v1

    Hopefully soon we will get a better option.

    I don’t believe it is an issue with OpenSSH though.

  • Hello Alice,

    The point Bernstein makes in the article I referenced is not so much that the NIST curves are suspect (for the reasons you mention) but the fact that the ECDSA algorithm itself is such that it is virtually impossible to implement in such a way that the code uses constant time. This opens the door for side channel (timing) attacks. The fact that you use a “nothing up my sleeve” curve does not change that fact.

    Regards, Leonard.

  • Hi,

    Rereading the article I’m not sure again if my last statement is correct… Perhaps Bernsteins objections against ECDSA are against ECDSA
    +NIST-curves (because those use parameters that make a constant time implementation hard?) and not vs ECDSA as such. “Every natural implementation of ECDSA” is a bit ambiguous in this respect…

    Regards, Leonard.


  • It is. As anything behind which secret [service] taxpayer money quite likely is. But the awful thing is that everyone of us who usees google anything, gmail included, are part of the problem. Yes, indeed, we need to look into mirror and answer honestly to ourselves about that. Disregarding that the truth hurts.

    Ironically, many of us displeased with google (vocally on this list that is) post from gmail accounts ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++