Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
Date: Fri, 14 Jul 2017 09:41:00 +0000 (UTC)
From: =?utf-8?Q?Marcin_=C5=81uczy=C5=84ski_=28JIRA=29?= <jira@apache.org>
To: dev@kafka.apache.org
Message-ID: <JIRA.13087145.1500025221000.246828.1500025260026@Atlassian.JIRA>
In-Reply-To: <JIRA.13087145.1500025221000@Atlassian.JIRA>
References: <JIRA.13087145.1500025221000@Atlassian.JIRA> <JIRA.13087145.1500025221317@jira-lw-us.apache.org>
Subject: [jira] [Created] (KAFKA-5591) Infinite loop during failed Handshake
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 14 Jul 2017 09:41:09 -0000

Marcin =C5=81uczy=C5=84ski 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 =C5=81uczy=C5=84ski
         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 sectio=
n [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://w=
ww.confluent.io/blog/apache-kafka-security-authorization-authentication-enc=
ryption/], 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.2=
0:55609 on /10.20.40.12:9093 and assigned it to processor 3, sendBufferSize=
 [actual|requested]: [102400|102400] recvBufferSize [actual|requested]: [10=
2400|102400] (kafka.network.Acceptor)
[2017-07-14 05:24:48,959] DEBUG Processor 3 listening to new connection fro=
m /10.20.40.20:55609 (kafka.network.Processor)
[2017-07-14 05:24:48,971] DEBUG SSLEngine.closeInBound() raised an exceptio=
n. (org.apache.kafka.common.network.SslTransportLayer)
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_no=
tify: 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:1=
561)
        at org.apache.kafka.common.network.SslTransportLayer.handshakeFailu=
re(SslTransportLayer.java:730)
        at org.apache.kafka.common.network.SslTransportLayer.handshake(SslT=
ransportLayer.java:313)
        at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChanne=
l.java:74)
        at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selec=
tor.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, s=
tate =3D 1, type =3D 1
        at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1487)
        at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.jav=
a: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.handshakeUnwra=
p(SslTransportLayer.java:411)
        at org.apache.kafka.common.network.SslTransportLayer.handshake(SslT=
ransportLayer.java:269)
        at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChanne=
l.java:74)
        at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selec=
tor.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 v=
iolation, state =3D 1, type =3D 1
        at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshake=
r.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:14=
16)
        at org.apache.kafka.common.network.SslTransportLayer.runDelegatedTa=
sks(SslTransportLayer.java:335)
        at org.apache.kafka.common.network.SslTransportLayer.handshakeUnwra=
p(SslTransportLayer.java:416)
        ... 7 more
{quote}

Which is ok obviously for the broken trust store case. However my client ap=
p did not receive any exception or error message back. It did not stop eith=
er. Instead it fell into a infinite loop of re-tries, generating huge log w=
ith 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 t=
o find it.

I attached the store I used, but I suppose any will do reproduce the proble=
m - it's enough that it's not generated properly and causes handshake to fa=
il.


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