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
On CentOS 7 I put the following at the end of ssh
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
I believe that prevents the CBC ciphers from being used.
CentOS 6 I *think* does not support curve25519 so that one may not be an option for CentOS 6. That really should be patched in CentOS 5 and 6.
For the DH key exchange, I generate custom 2048 and 4096 DH keys
pushd /etc/ssh ssh-keygen -G moduli-2048.candidates -b 2048 ssh-keygen -T moduli-2048 -f moduli-2048.candidates ssh-keygen -G moduli-4096.candidates -b 4096 ssh-keygen -T moduli-4096 -f moduli-4096.candidates
cp moduli moduli-backup cat moduli-2048 moduli-4096 > moduli
systemctl restart sshd.service
On 10/18/2016 03:28 PM, Clint Dilks wrote:
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 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/18/2016 03:28 PM, Clint Dilks wrote:
So first question is are people generally modifying the list of ciphers supported by the ssh client and sshd?
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.
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.
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.
Is just using these three ciphers like to cause me any problems? Could having so few ciphers be creating a security concern itself?
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 gordon.messmer@gmail.com:
On 10/18/2016 03:28 PM, Clint Dilks wrote:
So first question is are people generally modifying the list of ciphers supported by the ssh client and sshd?
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.
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.
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.
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 ...
Is just using these three ciphers like to cause me any problems? Could having so few ciphers be creating a security concern itself?
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.
-- LF
On 2016-10-19 03:11, Leon Fauster wrote:
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 elaxdal@ece.uvic.ca said:
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.
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).
Am 19.10.2016 um 17:05 schrieb Chris Adams linux@cmadams.net:
Once upon a time, Erik Laxdal elaxdal@ece.uvic.ca said:
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.
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).
That was my assumption.
The best way is to run "ssh -Q cipher" (as mentioned in the ssh_config and sshd_config man pages under Ciphers).
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.
-- LF
Hello Clint,
On Wed, 2016-10-19 at 11:28 +1300, Clint Dilks wrote:
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
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:30 schrieb Leonard den Ottolander leonard@den.ottolander.nl:
Hello Clint,
On Wed, 2016-10-19 at 11:28 +1300, Clint Dilks wrote:
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
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.
Isn't there a collision attack for DES?
-- LF
On 10/19/2016 08:30 AM, Leonard den Ottolander wrote:
Where did you get the idea that AES (~ Rijndael) is a weak cipher?
It's not the cipher, but the mode. CBC has several known weaknesses in TLS, and is frequently regarded as potentially insecure as a result.
Hello Gordon,
On Wed, 2016-10-19 at 10:31 -0700, Gordon Messmer wrote:
On 10/19/2016 08:30 AM, Leonard den Ottolander wrote:
Where did you get the idea that AES (~ Rijndael) is a weak cipher?
It's not the cipher, but the mode. CBC has several known weaknesses in TLS, and is frequently regarded as potentially insecure as a result.
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.
On 10/19/2016 11:34 AM, Leonard den Ottolander wrote:
Hello Gordon,
*snip*
Personally I would be more concerned whether or not to enable ECDSA algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).
Regards, Leonard.
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.
Alice Wonder wrote:
On 10/19/2016 11:34 AM, Leonard den Ottolander wrote:
Hello Gordon,
*snip*
Personally I would be more concerned whether or not to enable ECDSA algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).
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.
Oh, are those the ones with the NSA backdoor curve?
mark
On 10/19/2016 01:54 PM, m.roth@5-cent.us wrote:
Alice Wonder wrote:
On 10/19/2016 11:34 AM, Leonard den Ottolander wrote:
Hello Gordon,
*snip*
Personally I would be more concerned whether or not to enable ECDSA algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).
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.
Oh, are those the ones with the NSA backdoor curve?
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,
On Wed, 2016-10-19 at 14:22 -0700, Alice Wonder wrote:
I formerly used secp521r1 but suddenly Google with no warning stopped supporting it in chrome. That company is too powerful.
Actually this is something the NSA insists on:
https://www.iad.gov/iad/customcf/openAttachment.cfm?FilePath=/iad/library/ia...
Q: To whom is the CNSS Advisory Memorandum 02-15 addressed? A: NSA's announcement of changes from Suite B cryptography to the Commercial National Security Algorithm Suite are for organizations that run classified or unclassified national security systems (NSS) and vendors that build products used in NSS. <snip>
I suppose Google is such a vendor.
Q: Can I use the NIST P-521 curve for ECDH or ECDSA on NSS? A: In order to enhance system interoperability NSA recommends the use of NIST P-384. CNSSP-15 does not permit use of NIST P-521. Use of NIST P-521 needs to be approved by NSA as an exception to policy. This continues under CNSS Advisory Memorandum 02-15.
Because of "interoperability" the use of strong crypto is discouraged.
Reminds me of the fact that not so long ago (and quite a while after the algorithm was considered broken) openwall (then org, now com) insisted on standardizing on MD5 for password hashes in phpass "because the algorithm is available on nearly every system." As if catering for the lowest common denominator is good practice when security is a concern.
Regards, Leonard.
On Thu, October 20, 2016 7:38 am, Leonard den Ottolander wrote:
Hello Alice,
On Wed, 2016-10-19 at 14:22 -0700, Alice Wonder wrote:
I formerly used secp521r1 but suddenly Google with no warning stopped supporting it in chrome. That company is too powerful.
<rant> 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. </rant>
Ironically, many of us displeased with google (vocally on this list that is) post from gmail accounts ;-)
Valeri
Actually this is something the NSA insists on:
https://www.iad.gov/iad/customcf/openAttachment.cfm?FilePath=/iad/library/ia...
Q: To whom is the CNSS Advisory Memorandum 02-15 addressed? A: NSA's announcement of changes from Suite B cryptography to the Commercial National Security Algorithm Suite are for organizations that run classified or unclassified national security systems (NSS) and vendors that build products used in NSS. <snip>
I suppose Google is such a vendor.
Q: Can I use the NIST P-521 curve for ECDH or ECDSA on NSS? A: In order to enhance system interoperability NSA recommends the use of NIST P-384. CNSSP-15 does not permit use of NIST P-521. Use of NIST P-521 needs to be approved by NSA as an exception to policy. This continues under CNSS Advisory Memorandum 02-15.
Because of "interoperability" the use of strong crypto is discouraged.
Reminds me of the fact that not so long ago (and quite a while after the algorithm was considered broken) openwall (then org, now com) insisted on standardizing on MD5 for password hashes in phpass "because the algorithm is available on nearly every system." As if catering for the lowest common denominator is good practice when security is a concern.
Regards, Leonard.
-- mount -t life -o ro /dev/dna /genetic/research
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Hello Alice,
On Wed, 2016-10-19 at 13:40 -0700, Alice Wonder wrote:
On 10/19/2016 11:34 AM, Leonard den Ottolander wrote:
Personally I would be more concerned whether or not to enable ECDSA algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).
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.
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,
On Thu, 2016-10-20 at 13:47 +0200, Leonard den Ottolander wrote:
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.
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.
On Thu, Oct 20, 2016 at 4:30 AM, Leonard den Ottolander < leonard@den.ottolander.nl> wrote:
Hello Clint,
On Wed, 2016-10-19 at 11:28 +1300, Clint Dilks wrote:
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
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.
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
-- mount -t life -o ro /dev/dna /genetic/research
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Alice Wonder -
Chris Adams -
Clint Dilks -
Erik Laxdal -
Gordon Messmer -
Leon Fauster -
Leonard den Ottolander -
m.roth＠5-cent.us -
Valeri Galtsev