[
https://issues.apache.org/jira/browse/KAFKA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Kornai updated KAFKA-19556:
---------------------------------
Description:
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}
was:
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 host
check. This should be driven by a configuration value that allows disabling the
SNI host check.
{code:java}
// In RestServer.java, when building the HTTPS connector
SecureRequestCustomizer customizer = new SecureRequestCustomizer();
customizer.setSniHostCheck(false);
HttpConfiguration https = new HttpConfiguration();
https.addCustomizer(customizer);
connector = new ServerConnector(jettyServer, ssl, new
HttpConnectionFactory(https)); {code}
> [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)
