You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Marcin Łuczyński (JIRA)" <ji...@apache.org> on 2017/07/14 09:41:00 UTC
[jira] [Created] (KAFKA-5591) Infinite loop during failed Handshake
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)