Hi Andreas,
The TLS code has run into changes in behavior across different Java
versions, so we only wanted to allow TLS 1.3 in the versions we tested
against. TLS 1.3 landed in Java 8 a while after we made the relevant
changes for Java 11 and newer. That said, Java 8 support is deprecated and
will be removed in Apache Kafka 4.0 (in a few months). So, it's not clear
we want to invest in making more features available for that version.
Thanks,
Ismael
On Thu, Oct 26, 2023 at 4:49 AM Andreas Martens1 <amart...@uk.ibm.com>
wrote:
> Hello good people of Kafka,
>
> I was recently informed that TLS 1.3 doesn’t work for connecting our
> product to Kafka, and after some digging realised it was true, no matter
> how hard I type “TLSv1.3” it doesn’t work, weirdly with an error about no
> applicable Ciphers.
>
> So after a bunch more digging I realised that the problem lies in the
> Kafka client classes, in Kafka clients’ SslConfigs.java there is this code:
> static {
> if (Java.IS_JAVA11_COMPATIBLE) {
> DEFAULT_SSL_PROTOCOL = "TLSv1.3";
> DEFAULT_SSL_ENABLED_PROTOCOLS = "TLSv1.2,TLSv1.3";
> } else {
> DEFAULT_SSL_PROTOCOL = "TLSv1.2";
> DEFAULT_SSL_ENABLED_PROTOCOLS = "TLSv1.2";
> }
> }
>
> My initial thoughts were that these just set the defaults, I should still
> be able to set TLSv1.3 in my properties, but no. If I change the above
> block to:
> static {
> DEFAULT_SSL_PROTOCOL = "TLSv1.3";
> DEFAULT_SSL_ENABLED_PROTOCOLS = "TLSv1.2,TLSv1.3";
> }
> it works just fine. I suspect (but haven’t yet had the time to verify)
> that there’s something that gets the list of supported Ciphers from the
> default, and applies those Ciphers to the selected end protocol, and since
> there’s no overlap I’m outta luck.
>
> Now of course life is never simple, so I can’t just make the above change
> and send you fine people a PR, since there’s probably still some older JREs
> out there that don’t support TLSv1.3.
>
> As a fine person once told me (actually, a Java support person) “don’t
> test the symptom, test the cause”. In this case, we shouldn’t be testing
> whether we’re working with a Java 11 JVM, we should test whether our
> current JVM has a TLSv1.3 Context instance. E.g.:
> try{
> SSLContext context = SSLContext.getInstance("TLSv1.3");
> DEFAULT_SSL_PROTOCOL = "TLSv1.3";
> }
> catch(java.security.NoSuchAlgorithmException e){
> DEFAULT_SSL_PROTOCOL = "TLSv1.2";
> }
> But the test in SslConfigs.java is done in *static* init, and as we all
> know, performing try-catch within a static is a Big No-No.
>
> Soooo, before I go digging further in the code and start looking to modify
> the places where the defaults are consumed, does anyone have a better idea?
> My initial thought was to raise a ticket and run away, but I’m trying to be
> a good citizen!
>
> I should probably mention, this code was introduced in
> https://issues.apache.org/jira/browse/KAFKA-7251 and
> https://issues.apache.org/jira/browse/KAFKA-9320 and
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
> .
>
> Thanks,
> Andreas Martens
> --
> Senior Engineer
> IBM App Connect Enterprise
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>
