We have recently upgraded our Tomcat version to 9.0.20 from Tomcat 7 and our users report that they are not able to connect to our system any longer due to the below error.
Error while sending message: Could not send Message. Peer sent alert: Alert Fatal: handshake failure
We have checked the SSL certificates and everything is in place and even we have verified the TLS version in the source SAP system. However this issue is noticed only in SAP systems who are using our webservices. So I would like to know what details I need to check at SAP side to fix this issue.
Please note that when I switch back to Tomcat7, the connection works perfectly fine. I have compared the server.xml of both the versions and don't see any difference apart from the below line.
Tomcat 7: protocol="HTTP/1.1"
Tomcat 9: protocol="org.apache.coyote.http11.Http11NioProtocol"
Appreciate response.
Thanks!
The issue was apparently with the cipher suites being used in SAP system. Adding new cipher suites which supports TLS 1.1 and TLS 1.2 worked and the issue was resolved.
Related
I have configured a ListenHTTP 1.7.0 processor in NiFi 1.7.0-RC1. It is listening on a custom port behind a reverse proxy. I have configured a StandardRestrictedSSLContextService with a JKS keystore and have added the keystore password. We have not configured the truststore as we don't expect to need mutual TLS. The certificate is signed by an internal enterprise CA and is (or should be!) trusted by the client.
When I test this with Chrome I receive the following:
This site can’t provide a secure connection
my.server uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.
Troubleshooting:
We have tried both TLS and TLSv1.2 in the ListenHTTP processor.
We have treid using curl (Linux) and Invoke-WebRequest (Windows) but have received variations on the bad cipher/SSL version message above.
I don't see anything in the release notes suggesting that the ListenHTTP processor changed much since 1.7.0, so I'm assuming that I don't need to upgrade NiFi.
Can anyone suggest what to try next or explain why we see this error?
I have read the following:
https://www.simonellistonball.com/technology/nifi-ssl-listenhttp/
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes
Nifi: how to make ListenHTTP work with SSL
What version of Java are you running on? Java 11 provides TLSv1.3, which is the default offering if you have generic TLS selected, but NiFi 1.7.0 doesn't support TLSv1.3 (and doesn't run on Java 11). So assuming you are running on Java 8, recent updates have introduced TLSv1.3 but should still provide for TLSv1.2. This can also indicate that the certificate you have provided is invalid or incompatible with the cipher suite list provided by the client. You can use $ openssl s_client -connect <host:port> -debug -state -CAfile <path_to_your_CA_cert.pem> to try diagnosing the available cipher suites & protocol versions. Adding -tls1_2 or -tls1_3, etc. will restrict the connection attempt to the specified protocol version as well.
You should definitely upgrade from NiFi 1.7.0 -- it was released over 2 years ago, has known issues, and there have been close to 2000 bug fixes and features added since, including numerous security issues. NiFi 1.12.1 is the latest released version.
The PHP version on my webserver was recently updated. Now I notice that when downloading external https URLs with Curl, for one specific server it fails, giving me this error:
SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Downloading https stuff from this server though Curl worked fine before.
Now the strange this is: it seems an SSL3 error, but as I understood from other cases regarding this error (also here on SO) it's due to SSL3 no longer being supported by updated versions of PHP or Curl. And rightly so, since SSL3 is insecure.
However, this particular webserver uses TLS1.2, and by no means SSL3.
So if my Curl is not using SSL3, and neither is the webserver, why am I still getting SSL3 related errors?
I already tried setting CURLOPT_SSLVERSION to 4, 5 or 6, and setting CURLOPT_SSL_CIPHER_LIST to TLSv1, all to no avail, error keeps coming up.
Although this error message looks like it is using SSL 3.0 it is probably not. Since TLS1.0 is practically SSL3.1 etc you will find lots of functions and error messages having the SSLv3 string within the TLS code path in OpenSSL. The problem with this specific server is probably something else and one would need to know the server hostname and your installed version of OpenSSL to find out more about the problem.
EDIT: Based on the comment the version of OpenSSL used with curl is 0.9.8b. Since the server can only do TLS 1.2 the handshake will fail, since TLS 1.2 is only supported since OpenSSL 1.0.1. Apart from that 0.9.8b is years out of support and has several security problems which got fixed in later versions.
I have been trying to configure a simple pass through proxy using wso2 esb, which points to a REST service in https port.
I had tried doing the same using my development machine (Windows 7) and it is successful.
But when I try repeating the same in production server, in RHEL, I get The system cannot infer the transport information error in system log.
Things Tried
Created passthrough proxy service pointing to https://some.domain.in/something/something.
Tried CURL to https://some.domain.in/something/something and its shows the response properly
Imported certificate from the site to client-truststore.jks. Same was done locally and it worked.
in axis2.xml, edited <parameter name="HostnameVerifier">AllowAll</parameter>under https transporter
Error Message
When clicked in test in configuration console, I got the following message, Invalid address
CURL the proxy service URL, and got Empty response
Checked system logs and saw below logs
Am I missing out something?
I could see in the wso2-error-logs following messages
ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O
error: handshake alert: unrecognized_name
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
Then I realised that I was using java 1.6 locally but 1.7 in production.
And in Java 1.7 there are some changes in SSL handling
The JDK 7 release supports
the Server Name Indication (SNI) extension in the JSSE client. SNI,
described in RFC 4366 enables TLS clients to connect to virtual
servers.
In order to bypass this, I added JAVA_OPTS="-Djsse.enableSNIExtension=false" in wso2server.sh and restarted.
This solved my problem.
Not sure if this is the correct way though
This url helped me finally
I am trying to install IHS certs in Websphere Application Server 8.5
and after I install the IHS WebServer certs I am getting
javax.net.ssl.SSLHandshakeException: no cipher suites in common.
I did not even touch the application server or go into the Cell Level
but both the IHS and the app server are on the same box.
Please help me resolve this and point out where and why is the root
cause for all this.
I don't know Websphere but you can get this kind of error if the server side has no certificates configured and thus falls back to the ADH ciphers (anonymous authentication). These ciphers are usually not supported by the clients, at least not by default and thus you get "no shared ciphers". Just a guess because of lack of more information in the question.
A client installed on jBOSS is trying to access a secured website configured on DataPower xi50v6.0.0.2 appliance. The connection is getting failed at SSL handshake.
I have taken a packet capture at DataPower and observed that SSL Handshake is failing with the Description:Handshake failure(40).
However, at the Client Hello step, I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
The TLS protocol used ( as per packet capture) is TLS1.1. Can this Cipher Suite be a problem?
In the DataPower system logs I can see below error:
Request processing failed: Connection terminated before request headers read because of the connection error occurs
Update:
The client application is running on jBOSS7.I have asked our jBOSS administrator to check the configuration at jBOSS end. I somehow got the access to server where jBOSS instance is installed and checked domain.xml where the ssl is configured. Where exactly in domain.xml, ths configuration related to cipher suites can be found?
I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV
This is no real cipher. If no other ciphers are specified then the client does not offer any ciphers at all which means that no shared ciphers can be found and thus the handshake will fail. It looks like the client is buggy. Reason might be a failed attempt to fight POODLE attack by disabling all SSL3.0 ciphers, which in effect disables all ciphers for TLS1 1.0 and TLS 1.1.