[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803448#comment-17803448
]
Stefan Miklosovic edited comment on CASSANDRA-18839 at 1/5/24 8:04 AM:
---
As I looked into trunk's PR again, I think that what was there is wrong,
because we were not distinguishing between SSLHandshakeException and
SSLException. The fact that an exception is an instance of SSLException does
not necessarily mean that it is SSLHandshakeException. So we might increase
handshake metrics when an exception was not a handshake one.
If we indeed want to make a distinction between SSLHandshakeException and more
general version of it, SSLException, I think this makes more sense:
https://github.com/apache/cassandra/pull/3018/commits/96f0f64dc7c36de97c1c18321cea1542937c8c66
For older branches, just acting on SSLException is fine because we are not
trying to update "handshake exception metrics" when we detect it.
was (Author: smiklosovic):
As I looked into trunk's PR again, I think that what was there is wrong,
because we were not distinguishing between SSLHandshakeException and
SSLException. The fact that an exception is an instance of SSLException does
not necessarily mean that it is SSLHandshakeException. So we might increase
handshake metrics when an exception was not a handshake one.
If we indeed want to make a distinction between SSLHandshakeException and more
general version of it, SSLException, I think this makes more sense:
https://github.com/apache/cassandra/pull/3018/commits/96f0f64dc7c36de97c1c18321cea1542937c8c66
For older branches, just acting on SSLException is fine because we are not
trying to update and "handshake exception metrics" when we detect it.
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by:
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801805#comment-17801805
]
Stefan Miklosovic edited comment on CASSANDRA-18839 at 1/2/24 2:32 PM:
---
[4.0 PR|https://github.com/apache/cassandra/pull/3015]
[4.1 PR|https://github.com/apache/cassandra/pull/3016]
[5.0 PR|https://github.com/apache/cassandra/pull/3017]
[trunk PR|https://github.com/apache/cassandra/pull/3018]
I created all branches. Patch from trunk applied quite cleanly to all older
branches but 4.0. It is colliding with this (1). In 4.0, I just logged that and
excluded call to ExceptionHandlers.logClientNetworkingExceptions because it
does not exist there yet.
As agreed, metrics are not anywhere but in trunk.
[~brandon.williams] [~maedhroz] does this make sense to you before I start to
build it all?
(1)
https://github.com/apache/cassandra/commit/d220d24994400d4342f5281f1a51514a6ae8c2fd
was (Author: smiklosovic):
[4.0 PR|https://github.com/apache/cassandra/pull/3015]
[4.1 PR|https://github.com/apache/cassandra/pull/3016]
[5.0 PR|https://github.com/apache/cassandra/pull/3017]
[trunk PR|https://github.com/apache/cassandra/pull/3018]
I created all branches. Patch from trunk applied quite cleanly to all older
branches but 4.0. It is colliding with this (1). In 4.0, I just logged that and
excluded call to ExceptionHandlers.logClientNetworkingExceptions because it
does not exist there yet.
As agreed, metrics are not anywhere but in trunk.
[~brandon.williams] does this make sense to you before I start to build it all?
(1)
https://github.com/apache/cassandra/commit/d220d24994400d4342f5281f1a51514a6ae8c2fd
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794663#comment-17794663
]
Stefan Miklosovic edited comment on CASSANDRA-18839 at 12/8/23 12:19 PM:
-
[~brandon.williams] I am thinking about the versions we want to see this in. Is
this really happening to 4.0+?
was (Author: smiklosovic):
[~brandon.williams] I am thinking about the versions we want to see this is. Is
this really happening to 4.0+?
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
> ... 15 common frames omitted {code}
--
This message was sent by Atlassian Jira
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793126#comment-17793126
]
Brad Schoening edited comment on CASSANDRA-18839 at 12/5/23 5:01 AM:
-
[~maxwellguo] we see these exclusively from "white hat" cyber security probes
ensuring disallowed ciphers and old SSL protocols are not functional. I'm not
sure metrics here would be very useful, although, not opposed if there is a
good use for them.
was (Author: bschoeni):
[~maxwellguo] we see these exclusively from "white hat" cyber security probes
ensuring disallowed ciphers and old SSL protocols are not functional. I'm not
sure metrics here would be very useful.
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
>
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788200#comment-17788200
]
Brad Schoening edited comment on CASSANDRA-18839 at 11/21/23 1:24 AM:
--
[~jameshu15869] looks about right. Have you been able to test it? If you
connect with an invalid certificate or obsolete SSL/Cypher it should then log
the error. Will probably want branch patches for 5.0, 4.1 and 4.0.
openssl s_client maybe one way to test the handshake with maybe trying _-tls1_1
(which is obsolete and should fail)_
was (Author: bschoeni):
[~jameshu15869] looks about right. Have you been able to test it? If you
connect with an invalid certificate or obsolete SSL/Cypher it should log the
error. Should probably have branch patches for 5.0, 4.1 and 4.0.
openssl s_client maybe one way to test the handshake with maybe trying
_-tls1_1._
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
>
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788200#comment-17788200
]
Brad Schoening edited comment on CASSANDRA-18839 at 11/21/23 12:46 AM:
---
[~jameshu15869] looks about right. Have you been able to test it? If you
connect with an invalid certificate or obsolete SSL/Cypher it should log the
error. Should probably have branch patches for 5.0, 4.1 and 4.0.
openssl s_client maybe one way to test the handshake with maybe trying
_-tls1_1._
was (Author: bschoeni):
[~jameshu15869] looks about right. Have you been able to test it? If you
connect with an invalid certificate or obsolete SSL/Cypher it should log the
error.
openssl s_client maybe one way to test the handshake with maybe trying
_-tls1_1._
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Assignee: James Hu
>Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
> at
> io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
> at
> io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
> at
>
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788140#comment-17788140
]
Brad Schoening edited comment on CASSANDRA-18839 at 11/20/23 7:33 PM:
--
[~jameshu15869] This section of the code has changed somewhat from 4.0.x to
trunk.
The exception occurs on line 261 of PreV5Handlers.java in exceptionCaught() in
the stack trace above, and has been moved to
ExceptionHandlers.logClientNetworkingExceptions in 4.1 & trunk which has added
several new instanceof checks. These are done so as to 'not spam the logs once
a bad client shows up' which is exactly the same issue I've seen with the SSL
errors.
So, using instanceof is correct here. Note that it might work best to handle
the parent SSLException, as these SSL exceptions don't benefit from having a
stack trace printed.
was (Author: bschoeni):
[~jameshu15869] This section of the code has changed somewhat from 4.0.x to
trunk.
The exception occurs on line 261 of PreV5Handlers.java in exceptionCaught() in
the stack trace above, and has been moved to
ExceptionHandlers.logClientNetworkingExceptions in trunk (5.x) which has added
several new instanceof checks. These are done so as to 'not spam the logs once
a bad client shows up' which is exactly the same issue I've seen with the SSL
errors.
So, using instanceof is correct here. Note that it might work best to handle
the parent SSLException, as these SSL exceptions don't benefit from having a
stack trace printed.
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
>
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787680#comment-17787680
]
James Hu edited comment on CASSANDRA-18839 at 11/19/23 10:54 PM:
-
[~bschoeni] IntelliJ says that SSLHandshakeException is never thrown in the
corresponding try block. Is that intended behavior? If so, I put together the
code below. Is ctx.channel().remoteAddress() what we were looking for in the
log? Also, I couldn't seem to find javadocs sites for Cassandra online - is
there a way to generate the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
was (Author: JIRAUSER303103):
[~bschoeni] IntelliJ says that SSLHandshakeException is never thrown in the
corresponding try block. Is that intended behavior? If so, I put together the
code below. Is ctx.channel().remoteAddress() what we were looking for in the
log? I couldn't seem to find javadocs sites for Cassandra online - is there a
way to generate the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
>
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787680#comment-17787680
]
James Hu edited comment on CASSANDRA-18839 at 11/19/23 10:52 PM:
-
[~bschoeni] IntelliJ says that SSLHandshakeException is never thrown in the
corresponding try block. Is that intended behavior? If so, I put together the
code below. Is ctx.channel().remoteAddress() what we were looking for in the
log? I couldn't seem to find javadocs sites for Cassandra online - is there a
way to generate the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
was (Author: JIRAUSER303103):
IntelliJ says that SSLHandshakeException is never thrown in the corresponding
try block. Is that intended behavior? If so, I put together the code below. Is
ctx.channel().remoteAddress() what we were looking for in the log? I couldn't
seem to find javadocs sites for Cassandra online - is there a way to generate
the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
>
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787680#comment-17787680
]
James Hu edited comment on CASSANDRA-18839 at 11/19/23 10:51 PM:
-
IntelliJ says that SSLHandshakeException is never thrown in the corresponding
try block. Is that intended behavior? If so, I put together the code below. Is
ctx.channel().remoteAddress() what we were looking for in the log? I couldn't
seem to find javadocs sites for Cassandra online - is there a way to generate
the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
was (Author: JIRAUSER303103):
IntelliJ says that SSLHandshakeException is never thrown in the corresponding
try block. Is that intended behavior? If so, I put together the code below. Is
ctx.channel().remoteAddress() what we were looking for in the log? I couldn't
seem to find javadocs sites for Cassandra online - is there a way to generate
the documentation to read/search through quickly?
{code:java}
try
{
...
}
catch (Throwable ex)
{
source.release();
if (Throwables.anyCauseMatches(ex, t -> t instanceof
SSLHandshakeException)) {
logger.warn("SSLHandshakeException in client networking with peer {}",
ctx.channel().remoteAddress(), ex);
return;
}
// Remember the streamId
throw ErrorMessage.wrap(ex, source.header.streamId);
} {code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
>
[jira] [Comment Edited] (CASSANDRA-18839) Catch SSLHandshakeExceptions exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787626#comment-17787626
]
James Hu edited comment on CASSANDRA-18839 at 11/19/23 4:50 PM:
[~bschoeni] Do you mean that an SSLHandshakeException handler should already be
in PreV5Handlers.java? I didn't seem to see anything explicitly in that file. I
was thinking it might make sense to add a case to
logClientNetworkingExceptions() at
[https://github.com/apache/cassandra/blob/ed5a22428355765df5da94151413fc59538afef5/src/java/org/apache/cassandra/transport/ExceptionHandlers.java#L113-L141]
to catch/log the SSLHandshakeException. I'm still new to Cassandra dev and
open source in general, so please let me know if I'm way off the mark here.
was (Author: JIRAUSER303103):
[~bschoeni] Do you mean that an SSLHandshakeException handler should already be
in PreV5Handlers.java? I didn't seem to see anything explicitly in that file. I
was thinking it might make sense to add a case to
logClientNetworkingExceptions() at
[https://github.com/apache/cassandra/blob/ed5a22428355765df5da94151413fc59538afef5/src/java/org/apache/cassandra/transport/ExceptionHandlers.java#L113-L141]
to catch/log the SSLHandshakeException. I'm still new to Cassandra dev and
open source in general, so please let me know if I'm way off the mark here.
{code:java}
{code}
> Catch SSLHandshakeExceptions exceptions
> ---
>
> Key: CASSANDRA-18839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18839
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brad Schoening
>Priority: Low
>
> When SSL connection errors occur, they tend to flood the log with stack
> traces and lack the identity of the remote client IP. Instead,
> PreV5Handlers.decode() could catch SSLHandshakeException and provide a brief,
> more informative WARN level message instead of the verbose and mostly
> unhelpful stack trace.
> I.e.,
> {code:java}
> [WARN ] [epollEventLoopGroup-5-5] cluster_id=3 ip_address=10.0.0.1
> PreV5Handlers.java:261 - SSLHandshakeException in client networking with peer
> 10.0.0.10:9042 error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE {code}
> instead of the current ones which flood the logs:
> {code:java}
> 2023-09-12 00:00:25,368 [WARN ] [epollEventLoopGroup-5-5] cluster_id=3
> ip_address=10.0.0.1 PreV5Handlers.java:261 - Unknown exception in client
> networking
> io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
> error:10d7:SSL routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
> at
> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: javax.net.ssl.SSLHandshakeException: error:10d7:SSL
> routines:OPENSSL_internal:SSL_HANDSHAKE_FAILURE
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:1031)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1321)
> at
> io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
> at
>
