[
https://issues.apache.org/jira/browse/KAFKA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18014150#comment-18014150
]
Greg Harris commented on KAFKA-19556:
-------------------------------------
[~tkornai] Thanks for the ticket!
I believe this would require a new configuration, and so is subject to our KIP
process:
[https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals]
This is a large time investment overall, and would only be possible to fix in a
new minor version of Connect. To avoid falling behind new versions, I would
recommend finding another workaround that does not involve code changes.
Personally, I'm not very familiar with SNI host checking, but I assume that
Jetty has enabled it by default as part of encouraging security "best
practices." Perhaps it is best to conform to the new default, rather than
invest effort in returning to the old behavior. We can also see from other
users how important this functionality is.
> [Connect] Provide a configuration to disable SNI required and SNI host
> checking for the REST API
> ------------------------------------------------------------------------------------------------
>
> Key: KAFKA-19556
> URL: https://issues.apache.org/jira/browse/KAFKA-19556
> Project: Kafka
> Issue Type: Bug
> Components: connect
> Affects Versions: 4.0.0
> Reporter: Tamas Kornai
> Priority: Major
>
> h3. Summary
> The upgrade to Jetty 12 in Kafka 4.0 enables a strict SNI host check by
> default for the Connect REST API. This change breaks HTTPS request forwarding
> between Connect workers when they connect via IP address, causing requests to
> fail with a 400: Invalid SNI error.
> h3. The Problem
> Prior to Kafka 4.0, the Jetty server used for the Connect REST API did not
> enforce a strict match between the TLS SNI hostname and the HTTP Host header.
> With the upgrade to Jetty 12, this check is now enabled by default at the
> HTTP level. This causes legitimate HTTPS requests to fail in environments
> where the client connects using an IP address or a hostname that is not
> listed in the server's TLS certificate.
> This results in the following error:
> {code:java}
> org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> {code}
> h3. Impacted Use Case: Inter-Node Request Forwarding
> This change specifically breaks the request forwarding mechanism between
> Connect workers in a common deployment scenario:
> # A follower Connect instance needs to forward a REST request to the leader.
> # The follower connects directly to the leader's IP address over HTTPS.
> # Security is handled by mTLS certificates, often managed by a custom
> certificate provider.
> This setup worked flawlessly before Kafka 4.0. Now, because the follower
> connects via IP, the SNI check fails, and the forwarding mechanism is broken.
> h3. Proposed Solution
> This behavior cannot be disabled through any existing Kafka Connect
> configuration. To restore the previous functionality, a
> SecureRequestCustomizer must be programmatically configured in
> RestServer.java to disable the SNI required and the SNI host check flags.
> This should be driven by a configuration value that allows disabling these
> SNI related settings.
> {code:java}
> // In RestServer.java, when building the HTTPS connector
> SecureRequestCustomizer customizer = new SecureRequestCustomizer();
> customizer.setSniRequired(false);
> customizer.setSniHostCheck(false);
> HttpConfiguration https = new HttpConfiguration();
> https.addCustomizer(customizer);
> connector = new ServerConnector(jettyServer, ssl, new
> HttpConnectionFactory(https)); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
