We have observed below vulnerability in RHEL 7.9 servers and need help to close it.
Vulnerability:- Weak SSL/TLS key exchange
Protocol:- TSLv1.2
Name:- DHE
Key Size:- 1024
Expected Solution:- Ciphers with Key size 2048 bits for DHE.
Thank You,
Rupesh
for java app, you can apply the following to resolve your issue:
JAVA_OPTS="$JAVA_OPTS -Djdk.tls.ephemeralDHKeySize=2048"
However, this requires at least JDK/JRE: 7/8 to apply the parameter
You can refer to this doc for more reference: https://access.redhat.com/solutions/1498223
Thanks
Related
Using Python 3, I'm trying to connect using a SSL context to a remote SMTP host, but I get the following error:
[SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:1056)
Here's the code I use:
from smtplib import SMTP
import ssl, os, certifi
ssl_context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH, cafile=certifi.where())
ssl_context.options |= ssl.OP_NO_TLSv1
ssl_context.options |= ssl.OP_NO_TLSv1_1
ssl_context.load_cert_chain(os.path.join(certsdir, 'certificate.pem'), os.path.join(certsdir, 'id_rsa'))
ssl_context.load_dh_params(os.path.join(certsdir, 'dhparams.pem'))
ssl_context.check_hostname = False
ssl_context.verify_mode = ssl.CERT_NONE
smtp = SMTP(server_name)
smtp.connect((host, 25))
smtp.ehlo()
if smtp.has_extn('starttls'):
smtp.starttls(None, None, ssl_context)
smtp.ehlo()
smtp.mail(fromaddr)
smtp.rcpt(toaddr)
smtp.data(message)
smtp.quit()
Question: Is the issue on my end, or on the destination's server end? Is there something I can do to avoid this issue?
I use certifi for the list of certificates, that is based on Mozilla recommendations and is up-to-date.
Thank you for your help here.
Question: Is the issue on my end, or on the destination's server end?
The server is offering a weak DH key, the client (your script) wants a stronger key. The problem should usually be fixed at the server side. And note that your call of load_dh_params makes no sense since setting the DH key is only relevant for the server side.
Is there something I can do to avoid this issue?
Don't use DH ciphers in the first place. All modern clients support ECDHE ciphers which don't have this problem. DH is very slow anyway.
Usually the client would also choose a ECDHE cipher if offered and this error will not happen. While it might be that the TLS stack at the client is too old and prefers DH, such an old stack would usually not complain about a weak DH. It is thus more likely that the servers SSL stack is too old so that it does not offer the more modern ciphers the clients wants by default.
To make sure that no DH ciphers are offered by the client and thus ECDHE or RSA key exchange is used set the ciphers accordingly:
ssl_context.set_ciphers('DEFAULT:!DH')
Note though that RSA key exchange is considered obsolete too since it does not provide any forward secrecy. You might therefore try if the server can do without DH and without kRSA by using a cipher string of DEFAULT:!DH:!kRSA.
I'm using this example as a template in a server/client pair I wrote. I honestly don't understand all the details on how the secure connection is done. I understand the simple private/public RSA encryption. We encrypt with a public key, and only private keys can open it. Is it as simple here? (this is not the real question here)
So my question is: In my client part I used set_verify_mode(boost::asio::ssl::verify_none);. Does this jeopardize the secure connection I'm using? Is the connection still secure and encrypted?
No, it's not safe setting SSL_VERIFY_NONE. In this case if someone attack the connection the client won't be able to verify the sender's identity.
Detailed description of server and client behaviour for each flags on openssl site:
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html
I'm using ssl3 to connect to server. When the -change_session_version option is specified with the -reconnect, I want the session protocol to change to SSLv2 from SSLv3
This is my command: apps/openssl s_client -connect 10.102.113.3:443 -reconnect -change_session_version -ssl3
Now, I know that I should have either this code:
if(change_session_version)
s->session->ssl_version = SSL2_VERSION;
Or this code:
if(change_session_version)
s->version = SSL2_VERSION;
I don't know where to put this code though.
I have declared change_session_version as an int in ssl.h and have set it to 1 if the -change_session_version option is specified.
Please help me out!
Your question embodies a contradiction in terms. A 'session' in SSL comprises the protocol, the cipher suite, the key material, and the peer certificates. You can't change any of them without creating a new session.
EDIT Just changing a variable in a piece of local memory can't possibly accomplish anything useful. The peer won't know about it, and the other peers sharing the session on other connections won't know about it either. You have to re-handshake and negotiate a new session.
I don't think this is possible. First, SSLv2 is practically not supported anymore and most stacks don't even implement it while the others have disabled it. And then there is no support for session resumption in SSLv2 at all.
In SSL connections. As far as I understand that the the order of the cipher suit that the client offers to the server matters. How can I know what is the order of the client's offered cipher suit in my Firefox or IE browsers?
In FF, I tried to type about:config and then filtered the output to: security.ssl, I got:
Is this is the exact order that the client offers to SSL servers? Does this means, my browser prefers DHE and ECDHE over RSA key exchange because the DHE and ECDHE ciphers came first?
There is nothing in the TLS RFC that says the order matters. Specific servers may choose to honor the order provided by the client as an order of preference, but it isn't required, and neither JSSE not OpenSSL does so to the best of my knowledge.
What is the highest encryption bit that is currently usable on the latest browsers. I have seen providers issuing 128 and 256 bit certificates. Are higher bit certificates usable in browsers? Are they publicly available ? Also is 128 / 256 bit still unbreakabale based on today's computing power ?
Thanks,
Murtaza
I have seen providers issuing 128 and 256 bit certificates.
No, you haven't. Not recently anyway. The key sizes in the certificates tend to be 1024, 2048 or above. (It's not recommended to go below 2048 nowadays.)
What makes the encryption key size (128 or 256 bits) isn't the size of the key in the certificate. The key in the certificate is used for asymmetric cryptographic, which takes place during the SSL/TLS handshake to perform an authenticated exchange of symmetric key (negotiated for this SSL/TLS session).
This symmetric key is used for encryption, and its size can indeed be 128 or 256 bits, typically. The size is dictated by the cipher suite that is negotiated (e.g. something based on AES-128 or AES-256). This key size is independent of the certificate's key size.