How to solve SWEET32 and Logjam vulnerabilities in weblogic nodemanger process - encryption

I got below vulnerabilities for NodeManager service in Weblogic version 12.1.3.0.0 and JDK 1.8.0_101-b13
{
"port": 5556,
"serviceName": "remotewatch?",
"protocol": "tcp",
"severity": 2,
"pluginID": 42873,
"pluginName": "SSL Medium Strength Cipher Suites Supported (SWEET32)",
"pluginFamily": "General",
"description": "The remote host supports the use of SSL ciphers that offer medium strength encryption. Nessus regards medium strength as any encryption that uses key lengths at least 64 bits and less than 112 bits, or else that uses the 3DES encryption suite.\n\nNote that it is considerably easier to circumvent medium strength encryption if the attacker is on the same physical network.",
"fname": "ssl_medium_supported_ciphers.nasl",
"pluginModificationDate": "2019/02/28",
"pluginType": "remote",
"riskFactor": "Medium",
"scriptVersion": "1.20",
"solution": "Reconfigure the affected application if possible to avoid use of medium strength ciphers.",
"synopsis": "The remote service supports the use of medium strength SSL ciphers.",
"pluginOutput": "\n Medium Strength Ciphers (> 64-bit and < 112-bit key, or 3DES)\n\n EDH-RSA-DES-CBC3-SHA Kx=DH Au=RSA Enc=3DES-CBC(168) Mac=SHA1 \n ECDHE-RSA-DES-CBC3-SHA Kx=ECDH Au=RSA Enc=3DES-CBC(168) Mac=SHA1 \n DES-CBC3-SHA Kx=RSA Au=RSA Enc=3DES-CBC(168) Mac=SHA1 \n\nThe fields above are :\n\n {OpenSSL ciphername}\n Kx={key exchange}\n Au={authentication}\n Enc={symmetric encryption method}\n Mac={message authentication code}\n {export flag}\n",
"cve": "CVE-2016-2183",
"complianceCheckName": null,
"complianceActualValue": null
}
{
"port": 5556,
"serviceName": "remotewatch?",
"protocol": "tcp",
"severity": 1,
"pluginID": 83875,
"pluginName": "SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam)",
"pluginFamily": "Misc.",
"description": "The remote host allows SSL/TLS connections with one or more Diffie-Hellman moduli less than or equal to 1024 bits. Through cryptanalysis, a third party may be able to find the shared secret in a short amount of time (depending on modulus size and attacker resources). This may allow an attacker to recover the plaintext or potentially violate the integrity of connections.",
"fname": "ssl_logjam.nasl",
"pluginModificationDate": "2019/11/27",
"pluginType": "remote",
"riskFactor": "Low",
"scriptVersion": "1.24",
"solution": "Reconfigure the service to use a unique Diffie-Hellman moduli of 2048 bits or greater.",
"synopsis": "The remote host allows SSL/TLS connections with one or more Diffie-Hellman moduli less than or equal to 1024 bits.",
"pluginOutput": "\nVulnerable connection combinations :\n\n SSL/TLS version : TLSv1.0\n Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_128_CBC_SHA\n Diffie-Hellman MODP size (bits) : 1024\n Warning - This is a known static Oakley Group2 modulus. This may make\n the remote host more vulnerable to the Logjam attack.\n Logjam attack difficulty : Hard (would require nation-state resources)\n\n SSL/TLS version : TLSv1.0\n Cipher suite : TLS1_CK_DHE_RSA_WITH_3DES_EDE_CBC_SHA\n Diffie-Hellman MODP size (bits) : 1024\n Warning - This is a known static Oakley Group2 modulus. This may make\n the remote host more vulnerable to the Logjam attack.\n Logjam attack difficulty : Hard (would require nation-state resources)\n\n SSL/TLS version : TLSv1.0\n Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_256_CBC_SHA\n Diffie-Hellman MODP size (bits) : 1024\n Warning - This is a known static Oakley Group2 modulus. This may make\n the remote host more vulnerable to the Logjam attack.\n Logjam attack difficulty : Hard (would require nation-state resources)\n\n SSL/TLS version : TLSv1.1\n Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_128_CBC_SHA\n Diffie-Hellman MODP size (bits) : 1024\n Warning - This is a known static Oakley Group2 modulus. This may make\n the remote host more vulnerable to the Logjam attack.\n Logjam attack difficulty : Hard (would require nation-state resources)\n\n SSL/TLS version : TLSv1.1\n Cipher suite : TLS1_CK_DHE_RSA_WITH_3DES_EDE_CBC_SHA\n Diffie-Hellman MODP size (bits) : 1024\n Warning - This is a known static Oakley Group2 modulus. This may make\n the remote host more vulnerable to the Logjam attack.\n Logjam attack difficulty : Hard (would require nation-state resources)\n\n SSL/TLS version : TLSv1.1\n Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_256_CBC_SHA\n Diffie-Hellman MODP size (bits) : 1024\n Warning - This is a known static Oakley Group2 modulus. This may make\n the remote host more vulnerable to the Logjam attack.\n Logjam attack difficulty : Hard (would require nation-state resources)\n",
"cve": "CVE-2015-4000",
"complianceCheckName": null,
"complianceActualValue": null
}
I have tried to add "-Djdk.tls.ephemeralDHKeySize=2048" in the NodeManager process, but it didn't help.
Any comments/suggestions?

Have you verified if your NM process reflects the new DH key size? Or you can try to edit lib/security/java.security for java 1.8 version and change the key size to 2048 instead.
Changing minimum key length for Diffie-Hellman

Related

List all Openssl ciphers a server supports

Is it possible to list all Openssl ciphers a server supports?
It is not possible to ask a TLS server about all the supported ciphers. All one can do is to probe the server for a specific cipher and observe if it reports that the server will support this cipher or not. With openssl command line this would mean to use openssl s_client -no_tls1_3 -cipher ... for probing TLS 1.2 and lower ciphers and openssl s_client -tls1_3 -ciphersuites ... for TLS 1.3 ciphers.
Example for a successful handshake:
$ openssl s_client -no_tls1_3 -cipher AES128-GCM-SHA256 -connect google.com:443
...
SSL-Session:
Protocol : TLSv1.2
Cipher : AES128-GCM-SHA256
And for a failed handshake:
$ openssl s_client -no_tls1_3 -cipher AES128-SHA256 -connect google.com:443
...
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
There are several limits to this approach though:
One can only probe ciphers supported by the version of openssl in use, see openssl ciphers -V
Some server might limit specific ciphers to specific TLS protocol versions, like weaker ciphers only with TLS 1.0. So one also has to iterate over the various TLS protocol versions when probing
Some server limit ciphers only when specific ECC curves are announced as supported by the client
Some servers have different configurations for different domains on the same IP address
Thus, for the successful tests one can be sure that the cipher is supported. For unsuccessful tests one cannot be fully sure that the cipher is not supported since it might only be supported in a specific context. For ciphers not tested one has no idea if these are supported or not.

How to fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH error?

How to fix the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error?
In one of our CentOS server, we are encountering the following error in Chrome
A secure connection cannot be established because this site uses an unsupported protocol with Error Code - ERR_SSL_VERSION_OR_CIPHER_MISMATCH
We tried following command - openssl s_client -connect <<domain>>:<<port>> -tls1_2
It gives the following output. It doesn't provide a chain of certificates and negotiated cipher.
$ openssl s_client -connect <<domain>>:<<port>> -tls1_2
CONNECTED(00000003)
139874418423624:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
139874418423624:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1505770082
Timeout : 7200 (sec)
Verify return code: 0 (ok)
We checked available ciphers on VM using command - # /usr/bin/openssl ciphers -v. This command provides a list of available ciphers which also include ciphers supported by TLS 1.2
We also checked certificates. The same certs work on different servers.
Can someone please guide what is missing in this scenario?
When we use openssl, if the connection gets terminated with the alert 40 error, that means we should explicitly specify the servername in our command, so that the server can return the right certificate the client is expecting.
Specify the exact hostname you want with -servername parameter. E.g:
openssl s_client -connect yourserver.domain.com:443 -servername yourserver.domain.com

How can I allow sha1WithRSAEncryption during nginx ssl_client_verify?

My nginx server is successfully verifying most (expected) client certificates, but some older client certificates are getting "400 Bad Request The SSL certificate error" and producing this log entry -- "client SSL certificate verify error: (68:CA signature digest algorithm too weak)"
Is there a way to allow older signature digest algorithms?
Running openssl list -digest-algorithms shows sha1RSA, but it isn't included in the TLSv1.2 - Handshake Protocol - Certificate Request Message.
Versions:
- helm chart nginx-ingress v1.1.3
- nginx-ingress-controller v0.21.0
- nginx v1.15.6
- openssl 1.1.1
-- Update --
To verify client certificates that are signed with weak digest algorithms, append #SECLEVEL=0 to your ssl_ciphers list, i.e. ssl_ciphers 'HIGH:!aNULL:!MD5#SECLEVEL=0';
discussion and openssl reference.
I don't understand the full implications of #SECLEVEL, so best solution is to push for updated client certificates!

How to identify and remove CBC ciphers in the CipherSuite?

I have apache http server with below ciphers in the cipherSuite. After a scan I found some of the ciphers(CBC) are weak and need to be removed. But I am unable to identify which of them are actually CBC. Can you please help?
FYI -
Versions are
Apache 2.4.23; openssl 1.0.2h; RHEL7
SSLCipherSuite:
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:
ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:
ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:
ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:
DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:
DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:
AES128-SHA256:AES256-SHA256:AES:DES-CBC3-SHA:
!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:
!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!3DES
CBC ciphers causing vulnerability: How to identify these in above suite?
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A*
I found some ciphers with "CBC3", but when I remove them Apache is not responding for https requests.
Any cipher with CBC in the name is a CBC cipher and can be removed. For improved security, you should also sort the ciphers from strongest to weakest and set SSLHonorCipherOrder on and SSLProtocol all -SSLv3 in your config.
Mozilla has a neat tool for generating secure webserver configurations that you might find useful, notably the modern cipher suite configuration for your Apache and OpenSSL version. After that, try the Qualsys SSL Labs Test to see how you did.

How to disable Null and Weak Ciphers on 389-Directory-Server

I am running 389-DS on CentOS. Version - '389-ds-base.i686 1.2.11.15-34.el6_5'.
Security scans revealed that NullCiphers were found on Port 389 and 636.
I tried to disable them by shutting down DS, editing the 'nsSSL3Ciphers' on all '/etc/dirsrv/slapd-/dse.ldif' files, and starting DS. nsSSL3Ciphers looks like this now -
modifyTimestamp: 20140915221826Z
nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,
+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo
rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs
a_export1024_with_des_cbc_sha
numSubordinates: 1
Scans are still showing Null Cipher on those 2 ports.
Here is the list of null SSL ciphers supported by the remote server :
Null Ciphers (no encryption)
TLSv1
NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1
The fields above are :
{OpenSSL ciphername}
Port
389 / tcp / ldap
636 / tcp / ldap
Any ideas on how i can disable these Null ciphers?
Set nsSSL3Ciphers to the following -
nsSSL3Ciphers: +all,-rsa_null_sha

Resources