Disable Warnings about TLSv1.0, TLSv1.1 and SSLv3

Elastic Stack Elasticsearch
1

I am currently running a ES7.10.2 with XPACK enabled on Linux servers. I was able to configure and run ES with no issues however I keep getting the following warns "Client requested protocol TLSv1 is not enabled or supported in server context". I get similar warns for TLSv1.1 and SSLv3.

My linux servers are configured to not have these protocols enabled and I don't want them enabled. So far, we haven't experienced any issues with using ES within our application but it is just filling up my logs with white noise.

Is there any debugging steps that can be done on the servers to see what is calling requesting these unsupported protocols or ways to suppress these types of warnings?

2

The full exception will look like this:

[2021-08-24T16:28:55,983][WARN ][o.e.h.AbstractHttpServerTransport] [node-0] caught exception while handling client http traffic, closing connection Netty4HttpChannel{localAddress=/10.0.15.23:9200, remoteAddress=/10.0.15.39:52003}
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 is not enabled or supported in server context
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471) ~[netty-codec-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) ~[netty-codec-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:615) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:578) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.49.Final.jar:4.1.49.Final]
        at java.lang.Thread.run(Thread.java:831) [?:?]
Caused by: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 is not enabled or supported in server context
        at sun.security.ssl.Alert.createSSLException(Alert.java:131) ~[?:?]
        at sun.security.ssl.Alert.createSSLException(Alert.java:117) ~[?:?]
        at sun.security.ssl.TransportContext.fatal(TransportContext.java:356) ~[?:?]
        at sun.security.ssl.TransportContext.fatal(TransportContext.java:312) ~[?:?]
        at sun.security.ssl.TransportContext.fatal(TransportContext.java:303) ~[?:?]
        at sun.security.ssl.ClientHello$ClientHelloConsumer.negotiateProtocol(ClientHello.java:882) ~[?:?]
        at sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:834) ~[?:?]
        at sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:812) ~[?:?]
        at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396) ~[?:?]
        at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1267) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1254) ~[?:?]
        at java.security.AccessController.doPrivileged(AccessController.java:691) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1199) ~[?:?]
        at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1542) ~[netty-handler-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1556) ~[netty-handler-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1440) ~[netty-handler-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1267) ~[netty-handler-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1314) ~[netty-handler-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501) ~[netty-codec-4.1.49.Final.jar:4.1.49.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440) ~[netty-codec-4.1.49.Final.jar:4.1.49.Final]
        ... 16 more

The first line says closing connection Netty4HttpChannel{localAddress=/10.0.15.23:9200, remoteAddress=/10.0.15.39:52003} and the remoteAddress identifies the client's address. There's no easy way to suppress these log messages (at least not without hiding lots of other logs too) so you should chase down these misconfigured clients and make them stop.

1 Like
3

You are correct in that is the full exception. However mine is is different in that localAddress is always 0.0.0.0 and that the remoteAddress is IP address of that specific node. So in my example below, I got the warning on es7102p-node-1 and the remoteAddress IP belongs to es7102p-node-1. For security reason I replaced the remoteAddress with x's to not expose it.

[2021-08-26T10:50:35,746][WARN ][o.e.h.AbstractHttpServerTransport] [es7102p-node-1] caught exception while handling client http traffic, closing connection Netty4HttpChannel{localAddress=0.0.0.0/0.0.0.0:9200, remoteAddress=/xx.xxx.xxx.xx:56300}

I will also note that we only get these warns when XPACK is enabled. Based on your last note, the misconfigured client would be my es7102p-node-1 server but that is a dedicated ES server for this cluster only. Each node is on a separate server, with each server only have ES on it and is only used for that specific node. Could there be anything with ES that would cause this warning?

4

I think your local address will be 0.0.0.0 if you are binding Elasticsearch to all interfaces, so that's not unreasonable. I don't think Elasticsearch talks to itself over HTTP so I expect it's something else running on the same host. You should be able to use sudo netstat -antp or similar to identify the client process (using the port number to pick out a specific connection).

5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.