You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Piotr Smolinski (Jira)" <ji...@apache.org> on 2019/10/04 21:08:00 UTC
[jira] [Comment Edited] (KAFKA-8978) When TLS is applied, broker
sends the response frame length in separate TLS packet
[ https://issues.apache.org/jira/browse/KAFKA-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16944504#comment-16944504 ]
Piotr Smolinski edited comment on KAFKA-8978 at 10/4/19 9:07 PM:
-----------------------------------------------------------------
The actual source of the issue is:
[https://github.com/apache/kafka/blob/2.3.0/clients/src/main/java/org/apache/kafka/common/network/SslTransportLayer.java#L651-L652]
The NetworkSend class used by AbstractResponse class creates 2 buffers to be sent. The flush is called before sending each of the buffers. On the other hand client uses exactly the same code to send requests and the frames are not split.
was (Author: psmolinski):
The actual source of the issue is:
[https://github.com/apache/kafka/blob/2.3.0/clients/src/main/java/org/apache/kafka/common/network/SslTransportLayer.java#L651-L652]
The NetworkSend class used by AbstractResponse class creates 2 buffers to be sent. The flush is called after sending each of the buffers. On the other hand client uses exactly the same code to send requests and the frames are not split.
> When TLS is applied, broker sends the response frame length in separate TLS packet
> ----------------------------------------------------------------------------------
>
> Key: KAFKA-8978
> URL: https://issues.apache.org/jira/browse/KAFKA-8978
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 2.2.1
> Reporter: Piotr Smolinski
> Priority: Minor
> Attachments: Screenshot 2019-10-04 at 13.15.03.png, dump.pcap, keylog.txt
>
>
> The issue was discovered tracking the network dumps.
> Each frame in Kafka wire protocol is prefixed with the 32-bit integer which contains remaining frame length. When unencrypted TCP is used (PLAINTEXT), the 4 octets are sent inside the same TCP/IP packet as the rest of the frame (at least as long as the whole frame fits). When TLS is enabled, the buffer is flushed immediately after the length is written which results in 33-octets length TLS packet and 101-octets length wire frame carrying just 4 octets of data.
> In the attachments there is tcp dump and captured encryption keys executing metadata query with *kafkacat*.
> The capture was analysed with Wireshark built from the source code. The support for Kafka 2.3 and Kafka over TLS dissection was merged into the master branch, but it has not been released yet.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)