You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@kafka.apache.org by "Piotr Smolinski (Jira)" <ji...@apache.org> on 2019/10/04 11:19:00 UTC

[jira] [Created] (KAFKA-8978) When TLS is applied, broker sends the response frame length in separate TLS packet

Piotr Smolinski created KAFKA-8978:
--------------------------------------

             Summary: 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
         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)