Although I mention ssh-dss for HostKeyAlgorithms in /etc/ssh/ssh_config. ssh-rsa key pair can be used to login!
HostKeyAlgorithms ssh-dss
Some useful info on the above issue
In practice, a RSA key will work everywhere. ECDSA support is newer, so some old client or server may have trouble with ECDSA keys. A DSA key used to work everywhere, as per the SSH standard (RFC 4251 and subsequent), but this changed recently: OpenSSH 7.0 and higher no longer accept DSA keys by default.
Related
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
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 am testing SSL, my use case is if the client wants to do a Renegotiation but propose different set of ciphers this time, is there a way this could be tested with openssl s_client. I know R will send a Reneg request, but how do I include Ciphers also?
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.
The question is pretty clear. I'm wondering if it uses a hashing algorithm, or it is simply an encryption. If it is a hash, then what algorithm is used (md5, sha1, etc)? Also, does the router compare the password in plain text for validation or a hash?
In WPA-PSK, the WPA passphrase and SSID are used to derive the 256 AES key used to encrypt the wireless traffic. The key derivation function is PBKDF2, defined in RFC 2898. If the passphrase for the SSID is correct the encryption will work so that the client can successfully communicate with the AP. Otherwise, the communication will fail. That's how the AP knows the passphrase is correct (the traffic isn't gibberish).