[
https://issues.apache.org/jira/browse/KAFKA-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16944504#comment-16944504
]
Piotr Smolinski commented on KAFKA-8978:
----------------------------------------
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)
