kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin Łuczyński (JIRA) <j...@apache.org>
Subject [jira] [Created] (KAFKA-5591) Infinite loop during failed Handshake
Date Fri, 14 Jul 2017 09:41:00 GMT
Marcin Łuczyński created KAFKA-5591:
---------------------------------------

             Summary: Infinite loop during failed Handshake
                 Key: KAFKA-5591
                 URL: https://issues.apache.org/jira/browse/KAFKA-5591
             Project: Kafka
          Issue Type: Bug
          Components: clients
    Affects Versions: 0.11.0.0
         Environment: Linux x86_64 x86_64 x86_64 GNU/Linux
            Reporter: Marcin Łuczyński
         Attachments: client.truststore.jks

For testing purposes of a connection from my client app to my secured Kafka broker (via SSL)
I followed preparation procedure described in this section [http://kafka.apache.org/090/documentation.html#security_ssl].
There is a flow there in description of certificates generation. I was able to find a proper
sequence of generation of certs and keys on Confluent.io [https://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption/],
but before that, when I used the first trust store I generated, it caused handshake exception
as shown below:

{quote}[2017-07-14 05:24:48,958] DEBUG Accepted connection from /10.20.40.20:55609 on /10.20.40.12:9093
and assigned it to processor 3, sendBufferSize [actual|requested]: [102400|102400] recvBufferSize
[actual|requested]: [102400|102400] (kafka.network.Acceptor)
[2017-07-14 05:24:48,959] DEBUG Processor 3 listening to new connection from /10.20.40.20:55609
(kafka.network.Processor)
[2017-07-14 05:24:48,971] DEBUG SSLEngine.closeInBound() raised an exception. (org.apache.kafka.common.network.SslTransportLayer)
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible
truncation attack?
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
        at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
        at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634)
        at sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1561)
        at org.apache.kafka.common.network.SslTransportLayer.handshakeFailure(SslTransportLayer.java:730)
        at org.apache.kafka.common.network.SslTransportLayer.handshake(SslTransportLayer.java:313)
        at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:74)
        at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:374)
        at org.apache.kafka.common.network.Selector.poll(Selector.java:326)
        at kafka.network.Processor.poll(SocketServer.scala:499)
        at kafka.network.Processor.run(SocketServer.scala:435)
        at java.lang.Thread.run(Thread.java:748)
[2017-07-14 05:24:48,971] DEBUG Connection with /10.20.40.20 disconnected (org.apache.kafka.common.network.Selector)
javax.net.ssl.SSLProtocolException: Handshake message sequence violation, state = 1, type
= 1
        at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1487)
        at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
        at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
        at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
        at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
        at org.apache.kafka.common.network.SslTransportLayer.handshakeUnwrap(SslTransportLayer.java:411)
        at org.apache.kafka.common.network.SslTransportLayer.handshake(SslTransportLayer.java:269)
        at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:74)
        at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:374)
        at org.apache.kafka.common.network.Selector.poll(Selector.java:326)
        at kafka.network.Processor.poll(SocketServer.scala:499)
        at kafka.network.Processor.run(SocketServer.scala:435)
        at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLProtocolException: Handshake message sequence violation, state
= 1, type = 1
        at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:213)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:966)
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:963)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1416)
        at org.apache.kafka.common.network.SslTransportLayer.runDelegatedTasks(SslTransportLayer.java:335)
        at org.apache.kafka.common.network.SslTransportLayer.handshakeUnwrap(SslTransportLayer.java:416)
        ... 7 more
{quote}

Which is ok obviously for the broken trust store case. However my client app did not receive
any exception or error message back. It did not stop either. Instead it fell into a infinite
loop of re-tries, generating huge log with exceptions as shown above. I tried to check if
there is any client app property that controls the number of re-attempts to connect, but I
failed to find it.

I attached the store I used, but I suppose any will do reproduce the problem - it's enough
that it's not generated properly and causes handshake to fail.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message