Hi Edoardo, Yes, that’s exactly what I’m saying!
If I run the console consumer in the build with: kafka-console-consumer.sh --bootstrap-server <server>:443 --topic <topic> --consumer.config $PWD/consumer.properties Where consumer.properties contains: sasl.mechanism=PLAIN security.protocol=SASL_SSL sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ username="<username>" \ password="<password>"; ssl.truststore.location=truststore.jks ssl.truststore.password=changeit ssl.truststore.type=JKS ssl.enabled.protocols=TLSv1.3 With Java 11 it works fine, but with Java 1.8 I get: [main] ERROR kafka.tools.ConsoleConsumer$ - Error processing message, terminating consumer process: org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate) at com.ibm.jsse2.aa.<init>(aa.java:9) at com.ibm.jsse2.ab.<init>(ab.java:44) at com.ibm.jsse2.bb.a(bb.java:129) at com.ibm.jsse2.bg.beginHandshake(bg.java:141) at org.apache.kafka.common.network.SslTransportLayer.startHandshake(SslTransportLayer.java:125) at org.apache.kafka.common.network.SslTransportLayer.handshake(SslTransportLayer.java:274) at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:178) at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:543) at org.apache.kafka.common.network.Selector.poll(Selector.java:481) at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:571) at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:281) at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:231) at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureCoordinatorReady(AbstractCoordinator.java:274) at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureCoordinatorReady(AbstractCoordinator.java:248) at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.coordinatorUnknownAndUnreadySync(ConsumerCoordinator.java:443) at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:475) at org.apache.kafka.clients.consumer.KafkaConsumer.updateAssignmentMetadataIfNeeded(KafkaConsumer.java:1296) at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1255) at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1235) at kafka.tools.ConsoleConsumer$ConsumerWrapper.receive(ConsoleConsumer.scala:473) at kafka.tools.ConsoleConsumer$.process(ConsoleConsumer.scala:103) at kafka.tools.ConsoleConsumer$.run(ConsoleConsumer.scala:77) at kafka.tools.ConsoleConsumer$.main(ConsoleConsumer.scala:54) at kafka.tools.ConsoleConsumer.main(ConsoleConsumer.scala) If I change the test in SslConfigs.java to test for presence of the TPSv1.3 protocol rather than testing for Java version, then both versions connect OK. Thanks, Andreas From: Edoardo Comar <edoardli...@gmail.com> Date: Friday, 3 November 2023 at 17:26 To: users@kafka.apache.org <users@kafka.apache.org> Cc: d...@kafka.apache.org <d...@kafka.apache.org> Subject: [EXTERNAL] Re: Java 1.8 and TLSv1.3 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 > > 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