Andreas,
do you mean that even if you configure your Java client running on Java8 with
ssl.enabled.protocols=TLSv1.3
you can't connect to a Kafka broker using TLS1.3 ?


On Sat, 28 Oct 2023 at 01:03, Ismael Juma <m...@ismaeljuma.com> wrote:
>
> 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
> >

Reply via email to