adutra opened a new issue, #15598:
URL: https://github.com/apache/iceberg/issues/15598
### Apache Iceberg version
1.10.1 (latest release)
### Query engine
None
### Please describe the bug 🐞
I believe there is a regression between Iceberg 1.10 and the upcoming 1.11
release related to TLS configuration in `HTTPClient`:
The `TLSConfigurer` class exposes a `hostnameVerifier()` method. Users can
leverage that method to provide custom verifiers.
In 1.10, hostname verification was entirely performed by the Apache HTTP
client, using the provided verifier.
In 1.11 however, hostname verification is now performed twice: at the socket
level (during handshake), and then at the HTTP client level (after handshake),
using the provided verifier. The first verification is done by the JSSE
provider and _does not leverage the verifier specified in `TLSConfigurer`_.
As a consequence, **TLS handshakes may now fail, whereas they would succeed
before**, for example if the server certificate can only be validated with a
custom verifier.
### Technical Details
In Iceberg 1.10 we use `httpclient5` version 5.5, where the
`DefaultClientTlsStrategy` constructor used by `HTTPClient` is as follows:
```java
public DefaultClientTlsStrategy(
final SSLContext sslContext,
final String[] supportedProtocols,
final String[] supportedCipherSuites,
final SSLBufferMode sslBufferManagement,
final HostnameVerifier hostnameVerifier) {
this(
sslContext,
supportedProtocols,
supportedCipherSuites,
sslBufferManagement,
HostnameVerificationPolicy.CLIENT, /* hostname verified only by the
HTTP client */
hostnameVerifier);
}
```
https://github.com/apache/httpcomponents-client/blob/c5bd9af6a47af3f2683209f0b818f1cf109026f6/httpclient5/src/main/java/org/apache/hc/client5/http/ssl/DefaultClientTlsStrategy.java#L124-L131
But in 1.11 we upgraded `httpclient5` to version 5.6, where the same
constructor becomes:
```java
public DefaultClientTlsStrategy(
final SSLContext sslContext,
final String[] supportedProtocols,
final String[] supportedCipherSuites,
final SSLBufferMode sslBufferManagement,
final HostnameVerifier hostnameVerifier) {
this(
sslContext,
supportedProtocols,
supportedCipherSuites,
sslBufferManagement,
null, /* CHANGED ! */
hostnameVerifier);
}
```
https://github.com/apache/httpcomponents-client/blob/cee67d86809aa23577968f9e7e7bf922a9892512/httpclient5/src/main/java/org/apache/hc/client5/http/ssl/DefaultClientTlsStrategy.java#L127
We are now passing `null` instead of `HostnameVerificationPolicy.CLIENT` to
the super constructor. But this change incurs in a subtle behavior change:
https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/ssl/AbstractClientTlsStrategy.java#L101
When the `hostnameVerifier` is non-null (which is always the case for
Iceberg), the verification strategy defaults to `BOTH` – not `CLIENT`. This is
why the verification is now done twice.
### Suggested Fix
* Expose a new method `HostnameVerificationPolicy
hostnameVerificationPolicy()` in `TLSConfigurer`.
* In order to restore 1.10 behavior, the method should by default return
`HostnameVerificationPolicy.CLIENT`.
* Construct the TLS strategy by using the new constructor that takes a
`HostnameVerificationPolicy` argument:
```java
new DefaultClientTlsStrategy(
tlsConfigurer.sslContext(),
tlsConfigurer.supportedProtocols(),
tlsConfigurer.supportedCipherSuites(),
SSLBufferMode.STATIC,
tlsConfigurer.hostnameVerificationPolicy(), /** ADDED */
tlsConfigurer.hostnameVerifier()));
```
### Willingness to contribute
- [x] I can contribute a fix for this bug independently
- [ ] I would be willing to contribute a fix for this bug with guidance from
the Iceberg community
- [ ] I cannot contribute a fix for this bug at this time
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
