[
https://issues.apache.org/jira/browse/CALCITE-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Maechler updated CALCITE-7796:
--------------------------------------
Description:
With {{hostname_verification=NONE,}} the remote driver is supposed to skip TLS
hostname verification. However, on Apache HttpClient >= 5.6 it doesn't anymore
and we start seeing hostname verification failures again. Avatica 1.28.0 itself
depends on HttpClient 5.5, where this still works, so the bug surfaces as soon
as a consumer resolves HttpClient 5.6 through another dependency (in our case,
a Quarkus BOM would pin 5.6.x since Quarkus 3.38).
---
{{CommonsHttpClientPoolCache.createTlsSocketStrategy}} builds the TLS strategy
as
{code:java}
new DefaultClientTlsStrategy(getSSLContext(config),
getHostnameVerifier(config.hostnameVerification()));
{code}
and relies on the default {{HostnameVerificationPolicy}} (added in HttpClient
5.4 with the values {{{}CLIENT{}}}, {{BUILTIN}} and {{{}BOTH{}}}). The
{{HostnameVerifier}} only controls HttpClient's own check after the handshake;
whether the JSSE endpoint identification runs during the handshake is decided
by the policy alone. Up to HttpClient 5.5 the two-argument constructor used
{{{}CLIENT{}}}, so {{NoopHostnameVerifier}} was the only check. Since 5.6
([this PR|https://github.com/apache/httpcomponents-client/pull/649]), the
constructor passes no policy, and\{{ AbstractClientTlsStrategy}} resolves the
default as {{BOTH}} when a verifier is supplied and {{BUILTIN}} when none is.
Both delegate hostname verification to the JSSE provider by calling
{{{}SSLParameters.setEndpointIdentificationAlgorithm("HTTPS"){}}}, so the check
runs during the TLS handshake and fails it before the verifier is ever
consulted. {{NONE}} therefore no longer disables anything.
was:
With {{hostname_verification=NONE,}} the remote driver is supposed to skip TLS
hostname verification. However, on Apache HttpClient >= 5.6 it doesn't anymore
and we start seeing hostname verification failures again. Avatica 1.28.0 itself
depends on HttpClient 5.5, where this still works, so the bug surfaces as soon
as a consumer resolves HttpClient 5.6 through another dependency (in our case,
a Quarkus BOM would pin 5.6.x since Quarkus 3.38).
h3. Cause
{{CommonsHttpClientPoolCache.createTlsSocketStrategy}} builds the TLS strategy
as
{code:java}
new DefaultClientTlsStrategy(getSSLContext(config),
getHostnameVerifier(config.hostnameVerification()));
{code}
and relies on the default {{HostnameVerificationPolicy}} (added in HttpClient
5.4 with the values {{{}CLIENT{}}}, {{BUILTIN}} and {{{}BOTH{}}}). The
{{HostnameVerifier}} only controls HttpClient's own check after the handshake;
whether the JSSE endpoint identification runs during the handshake is decided
by the policy alone. Up to HttpClient 5.5 the two-argument constructor used
{{{}CLIENT{}}}, so {{NoopHostnameVerifier}} was the only check. Since 5.6
([this PR|https://github.com/apache/httpcomponents-client/pull/649]), the
constructor passes no policy, and{{ AbstractClientTlsStrategy}} resolves the
default as {{BOTH}} when a verifier is supplied and {{BUILTIN}} when none is.
Both delegate hostname verification to the JSSE provider by calling
{{{}SSLParameters.setEndpointIdentificationAlgorithm("HTTPS"){}}}, so the check
runs during the TLS handshake and fails it before the verifier is ever
consulted. {{NONE}} therefore no longer disables anything.
> Avatica: `hostname_verification=NONE` has no effect with Apache HttpClient
> 5.6+
> -------------------------------------------------------------------------------
>
> Key: CALCITE-7796
> URL: https://issues.apache.org/jira/browse/CALCITE-7796
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Affects Versions: avatica-1.28
> Reporter: Andreas Maechler
> Priority: Major
>
> With {{hostname_verification=NONE,}} the remote driver is supposed to skip
> TLS hostname verification. However, on Apache HttpClient >= 5.6 it doesn't
> anymore and we start seeing hostname verification failures again. Avatica
> 1.28.0 itself depends on HttpClient 5.5, where this still works, so the bug
> surfaces as soon as a consumer resolves HttpClient 5.6 through another
> dependency (in our case, a Quarkus BOM would pin 5.6.x since Quarkus 3.38).
> ---
> {{CommonsHttpClientPoolCache.createTlsSocketStrategy}} builds the TLS
> strategy as
> {code:java}
> new DefaultClientTlsStrategy(getSSLContext(config),
> getHostnameVerifier(config.hostnameVerification()));
> {code}
> and relies on the default {{HostnameVerificationPolicy}} (added in HttpClient
> 5.4 with the values {{{}CLIENT{}}}, {{BUILTIN}} and {{{}BOTH{}}}). The
> {{HostnameVerifier}} only controls HttpClient's own check after the
> handshake; whether the JSSE endpoint identification runs during the handshake
> is decided by the policy alone. Up to HttpClient 5.5 the two-argument
> constructor used {{{}CLIENT{}}}, so {{NoopHostnameVerifier}} was the only
> check. Since 5.6 ([this
> PR|https://github.com/apache/httpcomponents-client/pull/649]), the
> constructor passes no policy, and\{{ AbstractClientTlsStrategy}} resolves the
> default as {{BOTH}} when a verifier is supplied and {{BUILTIN}} when none is.
> Both delegate hostname verification to the JSSE provider by calling
> {{{}SSLParameters.setEndpointIdentificationAlgorithm("HTTPS"){}}}, so the
> check runs during the TLS handshake and fails it before the verifier is ever
> consulted. {{NONE}} therefore no longer disables anything.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
