[
https://issues.apache.org/jira/browse/KAFKA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18013762#comment-18013762
]
oshione gabriel esiemokhai commented on KAFKA-19556:
----------------------------------------------------
Yes exactly so if there are multiple host names on the web server , without an
sni it is possible you can get an error if the web server does not know what
ssl to handshake you with. so there are some draw backs disabling this I think .
> [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)
