In DSE Cassandra, nodes I have added self signed certificate. Both the nodes are up but they are not able to communicate with other. I am getting the below exception:
ERROR [ACCEPT-/10.16.252.241] 2020-05-12 13:50:12,760 MessagingService.java:1412 - SSL handshake error for inbound connection from 6dd8b1d0[SSL_NULL_WITH_NULL_NULL: Socket[addr=/10.16.252.209,port=52938,localport=7001]]
javax.net.ssl.SSLHandshakeException: no cipher suites in common
Related
Note: I am running my python script on the same MQ Server. I am able to connect to Qmgr without ssl.
I am running IBM MQ on a server, Configured Qmgr with ssl and able to connect to it using IBM Explorer. I am trying to connect python application using pymqi library to MQ Qmgr with ssl connection. Using ssl am unable to connect to the Qmgr.
Steps performed:
Created a client.kdb key db and created a certificate using runmqakm utility extracted qmgr public certificate and added to the client.kdb key db and extracted client pub cert and added to the qmgr key db.
MQ version - v9.2
Python version - 3.6
OS - RHELinux
Error on python Script:
Traceback (most recent call last):
File "ssl-mq.py", line 32, in <module>
qmgr.connect_with_options(queue_manager, cd, sco)
File "/root/.local/lib/python3.6/site-packages/pymqi-1.12.10-py3.6-linux-x86_64.egg/pymqi/__init__.py", line 1747, in connect_with_options
raise MQMIError(rv[1], rv[2])
pymqi.MQMIError: MQI Error. Comp: 2, Reason 2393: FAILED: MQRC_SSL_INITIALIZATION_ERROR
Error on MQ - /var/mqm/errors/AMQERR01.LOG
A certificate encountered during SSL handshaking is regarded as bad for one of
the following reasons:
(a) it was formatted incorrectly and could not be validated
(b) it was formatted correctly but failed validation against the Certification
Authority (CA) root and other certificates held on the local system
(c) it was found in a Certification Revocation List (CRL) on an LDAP server
(d) a CRL was specified but the CRL could not be found on the LDAP server
(e) an OCSP responder has indicated that it is revoked
(f) The keysize of the certificate is too small for the configured limit.
(MinimumRSAKeySize)
Tried to add the root certificate to client keydb and refreshed the security settings on the mq qmgr.
How is security handled between Cassandra seeds and nodes? ie. How to prevent unauthorized replication of my datacenter by posing as my node? I could create a firewall with a whitelist, but is there another mechanism as well?
Enabling node-to-node SSL solves this issue. Essentially, a false node pretending to be legit shouldn't have a matching Java Truststore, and will thus be denied from joining the cluster.
I have seen in a balance transfer example of hyperledger fabric, stating that, the following setting skips the gossip handshake since we are are not doing mutual TLS
Refer: https://github.com/hyperledger/fabric-samples/blob/release/balance-transfer/artifacts/base.yaml
# The following setting skips the gossip handshake since we are
# are not doing mutual TLS
- CORE_PEER_GOSSIP_SKIPHANDSHAKE=true
Question: What is the relation with mutual TLS to skipping the handshake?
This is an old and deprecated option not in use since v1.1. While doing a handshake and in case of mutual TLS enabled gossip also authenticated TLS certificated, this option for a while allowed to skip it. Now, it's deprecated and not in use anymore.
I have configured my Tomcat 8.5 cipher suites as below
<Connector
....
sslEnabledProtocols="TLSv1.2"
ciphers="
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
... />
While testing the site with www.ssllabs.com I find strange result in Server Supported Cipher Suites section. The list is as below :
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 .... OK
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 .... WEAK
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA .... WEAK
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 .... OK
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 .... WEAK
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA .... WEAK
Where are the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 come from, I have not configure them in server.xml ?!
Is it any default list of cipher suites in tomcat ?!
When you specify ciphers, no additional ciphers will be made available, regardless of the capabilities of the cryptographic provider being used (e.g. JSSE, OpenSSL, etc.).
If you are seeing a different set of cipher suites being negotiated, I would check two things:
Your configuration is actually being used. Try adding a syntactic error to your XML configuration file to see if Tomcat still starts. Tomcat should refuse to start if the file is not well-formed, confirming that you are in fact changing the right configuration file.
If you are not directly connecting to Tomcat, you may be negotiating your TLS handshake with another network component such as a reverse proxy which is terminating TLS. If that's the case, the configuration of Tomcat is not relevant; the client is really talking to the reverse proxy and not to Tomcat, so the list of ciphers will be different as far as the client can tell. You will need to reconfigure the reverse proxy in this situation. The cipher suites list in Tomcat is still important, as you want to be using a secure cipher suite even "inside" your own network.
We've been having issues getting a successful SSL connection from a client app trying to connect using wininet on windows xp sp3 (ie v6). The client hello looks off to me, why would the hello state its version as SSL 2.0 and then state the handshake version as SSL 3.0? Is there something coded incorrectly from the app using wininet?
SSLv2 Record Layer: Client Hello
[Version: SSL 2.0 (0x0002)] <---------------------
Length: 76
Handshake Message Type: Client Hello (1)
Version: SSL 3.0 (0x0300) <---------------------
Cipher Spec Length: 51
Session ID Length: 0
Challenge Length: 16
Cipher Specs (17 specs)
Challenge
SSLv3 and TLSv1.x have a compatibility mode in case the client also supports v2 servers, as described in the TLS specification (Backward Compatibility With SSL).
Some clients support this. For example Oracle/Sun Java has an SSLv2Hello pseudo-protocol, which uses SSLv2 Hello, but doesn't actually support SSLv2.
I know this issue is solved but I will share some more info about the subject which may be useful for viewers
"The client sends a SSLv2 ClientHello so that a server who understands only SSLv2 can process that message, and continue with a SSLv2 handshake. But the SSLv2 ClientHello also says "by the way, I know SSLv3, so if you know SSLv3 too, let's do SSLv3 instead of SSLv2", which is what usually happens (servers who know only of SSLv2 are extremely rare nowadays)."
I took it from Thomas Pornin's comment, link
https://security.stackexchange.com/questions/34827/why-clients-offer-handshaking-with-ssl-2-0-protocol