We are currently in the process of migrating from Kafka 1.0 to Kafka 2.8, utilizing the Confluent's Kafka container image version 6.2.0. Our challenge lies in maintaining backward compatibility with devices in the field that use the TLSv1.1 protocol with AES128 bit encryption policy (based on Java-8's old policy).
Here are the key details:
The existing Confluent container image uses Java-11, in contrast to the older server which ran on Java-8. We have updated the Java security policy on the new container to enable TLSv1 and TLSv1.1. However, when communicating with the server, it still sends TLS cipher suites with AES256 (specifically ECDHE-RSA-AES256-GCM*).
Due to constraints, modifying the Java security settings on the field devices is not an option. Given these constraints, what additional settings or configurations can be adjusted on the new Confluent container to ensure compatibility with devices relying on AES128 encryption policies (specifically ECDHE-RSA-AES128-GCM*)?
We tried updating the Java security file to enable TLSV1,TLSV1.1. Modified kafka settings with custom ciphers.
There's nothing specific to that image you can set for TLS. There's env vars for setting Kafka server.properties or just JAVA_OPTS / JAVA_TOOL_OPTIONS that any Java container would accept, but modifying any of the JRE files directly is probably not going to work well for future upgrades
You could build your own Kafka image on Ternium or old AdoptOpenJDK 8 images, if you really need Java 8 still, but if the server itself no longer supports old TLS algorithms, then you'll need a different solution altogether. For example, "devices in the field" could use MQTT, then you use MQTT connector to forward to Kafka; this is one common use case in IOT industry
Worth pointing out that Kafka supports Java 17 now, and probably 21 LTS within the year, so only going to 11 might run into similar issues going forward