[
https://issues.apache.org/jira/browse/ZOOKEEPER-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170880#comment-17170880
]
Andor Molnar commented on ZOOKEEPER-3905:
-----------------------------------------
This is very odd, I cannot repro it with a real cluster/client.
If I try to create a client which provides a certificate that is not trusted,
I'll get a connection cannot be established error during SSL handshake.
Handshake fails essentially.
{noformat}
2020-08-04 16:50:09,883 [myid:1] - ERROR
[nioEventLoopGroup-7-4:NettyServerCnxnFactory$CertificateVerifier@363] -
Unsuccessful handshake with session 0x0
2020-08-04 16:50:09,884 [myid:1] - WARN
[nioEventLoopGroup-7-4:NettyServerCnxnFactory$CnxnChannelHandler@220] -
Exception caught
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
General SSLEngine problem
{noformat}
{{CertificateVerifier}} doesn't even try to authenticate the client, because
the handshake process failed previously.
Question: is it possible to provide a cerificate which is trusted by the
server, handshake completes and later {{CerificateVerifier}} fails to
authenticate?
It uses the same {{ZKTrustManager}} as SSLHandler and calls the same
{{checkClientTrusted()}} method.
We might double check the certificate in this process and CertificateVerifier
is redundant.
> Race condition causes sessions to be created for clients even though their
> certificate authentication has failed
> ----------------------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-3905
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3905
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.5.8
> Reporter: Karan Mehta
> Priority: Major
>
> To reproduce, apply the diff and run
> ClientSSLTest#testSecureStandaloneServer() test. The logs would show that a
> valid session was created before connection was rejected and client had to
> retry
>
> {code:java}
> diff --git
> a/zookeeper-server/src/main/java/org/apache/zookeeper/common/ZKTrustManager.java
>
> b/zookeeper-server/src/main/java/org/apache/zookeeper/common/ZKTrustManager.java
> index aa02145b2..df1bdcc0f 100644
> —
> a/zookeeper-server/src/main/java/org/apache/zookeeper/common/ZKTrustManager.java
> +++
> b/zookeeper-server/src/main/java/org/apache/zookeeper/common/ZKTrustManager.java
> @@ -111,6 +111,7 @@ public void checkServerTrusted(X509Certificate[] chain,
> String authType, SSLEngi
> @Override
> public void checkClientTrusted(X509Certificate[] chain, String authType)
> throws CertificateException
> { x509ExtendedTrustManager.checkClientTrusted(chain, authType); + throw new
> CertificateException(); }
> @Override
> {code}
>
> What should have happened:
> Server should instantly close the client's connection and NOT process any
> request.
>
> Potential threat:
> Malicious clients may be able to put unnecessary load/traffic on the leader
> by creating these sessions.
>
> Race Condition:
> In CertificateVerifier#operationComplete(), `addCnxn(cnxn)` method is only
> called after auth is completed. NettyServerCnxn#close() returns as a no-op
> [here|https://github.com/apache/zookeeper/blob/branch-3.5/zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxn.java#L105].
>
> I see this as an issue. Please assess the risk and let me know if this is a
> legit behavior or not.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
