This is closely related to
Using nxlog to ship logs in to logstash from Windows using om_ssl
Using SSL to ship from NXlog to Logstash
I have a working NXlog and Logstash configuration as described in the above links.
However, the TLS connection fails with following exception in the logstash log:
OpenSSL::SSL::SSLError: Client requested protocol SSLv3 not enabled or not supported
It seems that NXlog relies on SSLv3 instead of TLS 1.x to do the SSL handshake. However, the former has been disabled in recent Java versions (as used by logstash) due to the POODLE vulnerability.
So how can I disable SSLv3 on the client side and force NXlog to use TLS 1.2?
I have to answer this one myself (after getting help on the NXlog community forum).
TLS is only supported by nxlog-ce-2.9.1347 and later.
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.
I recently migrated a Home Assistant (HASSIO) instance from Ubuntu 18.04 to Ubuntu 20.04. While setting up MQTT, I noticed that TLS security option for MQTT was set as "tlsv1" and MQTT broker was reporting this as an error while starting the service:
Error: Unsupported tls_version "tlsv1"
I had to change this to a supported TLS version and tlsv1.3 did the trick. In /etc/mosquitto/conf.d/default.conf:
tls_version tlsv1.3
MQTT broker is now up and working. However Owntracks client from Android Phone has trouble connecting to the MQTT Broker. It constantly shows SSL Handshake error.
Any idea what could be wrong? Do I need to update the certificates on Owntracks to support the new TLS version?
After some head banging, it seems tls version 1.2 works fine without changing the CA certificates on the Android device. I tried all options - tlsv1.1, tlsv1.2 and tlsv1.3 and only tlsv1.2 seemed to work for now.
It also seems that TLS v1.3 is the most secure option and given a chance it should be used if possible. The only problem is that CA certificates are distributed across a number of my Android devices and this is more of a logistcs issue. However for the time being, below option in /etc/mosquitto/conf.d/default.conf works fine:
tls_version tlsv1.2
Hope this helps others facing similar problems.
I'm running a web application that communicates with various APIs. One API requires TLSv1.2 while another will not support something that current (TLSv1 or TLSv1.1).
Does Websphere support multiple SSL versions?
I've found documentation about successfully changing the version of SSL, however I really need to be able to run TLSv1.1 and 1.2 together (if that's even possible) or run one version for one application while another for another application.
According to documentation for setting up SSL in WebSphere, to support the use of TLS 1.0, 1.1 and 1.2, I need to enable SSL_TLSv2:
Question: WAS is act SSL client, What does remote SSL server support
only TLSv1.0 or TLSv1.1 and Similar WAS is act SSL Server, What does
Remote SSL client does support only TLSv1.0 or TLSv1.1 or TLSv1.2.
What to do in order to work such environments?
Answer: There is an alternative option, SSL_TLSv2, which will enable
support for TLSv1.0, TLSv1.1, and TLSv1.2 in the environment. Please
use this setting SSL_TLSv2 in environments where support for multiple
TLS protocols is required, or if you are not sure whether your WAS
environment interacts with other servers or clients using non-TLSv1.2
protocols then, you can configure WAS to use SSL_TLSv2 using same
steps as given in the above.
Note:
Without poddle fix and configured WAS to use SSL_TLSv2
SSL_TLSv2 ==> Enables all SSL v3.0 and TLS v1.0, v1.1 and v1.2
protocols. Accepts SSLv3 or TLSv1 hello encapsulated in an SSLv2
format hello.
If you installed Poddle fix (will disable SSLv3 ) and configured WAS
to use SSL_TLSv2
SSL_TLSv2 ==> Enables these three TLS v1.0, v1.1 and v1.2 protocols.
So, changing the QoS settings to SSL_TLSv2 allows SSL Handshakes to multiple TLS versions when required.
Considering the POODLE attack, I want to disable the SSLv3 in my web app deployed on IBM WebSphere 6. There are a few concerns I cant address:
1. How to disable SSL and enable TLS in WAS 6.0 and 6.1?
2. When a client hits the url of my application in browser, and the browser supports SSL, the request will be initiated with SSL. Is there such a possibility wherein end user will get a handshake exception as the WAS 6 will have SSL disabled?
3. Is there a change required in application configuration or changing web server properties will help?
You don't need to change anything in your application.
There is already fixpack provided for latest WebSphere versions - check this page Vulnerability in SSLv3 affects IBM WebSphere Application Server
For V6.1.0.0 through 6.1.0.47:
Apply Interim Fix PI28796 : Will upgrade you to IBM Java SDK Version 5.0 Service Refresh 16 Fix Pack 7 + APAR IV66111 for change to
disable SSLv3 by default.
6.0 is soo old, that I don't remember if it even supports TLS. You will have to dig in the admin console somewhere in SSL settings (the exact path might be different) Security > SSL > SSL_configuration_name and change the protocol to TLS.
If you access WebSphere via web server (Apache or IHS), then you need to disable SSLv3 on the web server instead of application server. For details see Vulnerability in SSLv3 affects IBM HTTP Server
Add the following directive to the httpd.conf file to disable SSLv3
and SSLv2 for each context that contains "SSLEnable":
# Disable SSLv3 for CVE-2014-3566
# SSLv2 is disabled in V8R0 and later by default, and in typical V7
# and earlier configurations disabled implicitly when SSLv3 ciphers
# are configured with SSLCipherSpec.
SSLProtocolDisable SSLv3 SSLv2
Stop and restart IHS for the changes to take affect.
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.