Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Hostname verifier for the Jetty connector #5278

Merged
merged 1 commit into from
Mar 23, 2023

Conversation

senivam
Copy link
Contributor

@senivam senivam commented Mar 8, 2023

No description provided.

Signed-off-by: Maxim Nesen <maxim.nesen@oracle.com>
@senivam senivam self-assigned this Mar 8, 2023
private static final ClientConfig getClientConfig(boolean enableSslHostnameVerification) {
final ClientConfig config = new ClientConfig();
return enableSslHostnameVerification ? config
.property(JettyClientProperties.ENABLE_SSL_HOSTNAME_VERIFICATION, Boolean.FALSE)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am confused with this.

If enableSslHostnameVerification == true, then the config contains the property JettyClientProperties.ENABLE_SSL_HOSTNAME_VERIFICATION = Boolean.FALSE

It looks to me it should be in vice-versa, is this intentional?.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or the other way around. Does the user need to set property(JettyClientProperties.ENABLE_SSL_HOSTNAME_VERIFICATION, Boolean.FALSE) when the custom hostnameverifier is registered? Maybe it can be set to false automatically, can it not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the given test is built in a way for default hostname verification to be failed.

    private static final String CLIENT_TRUST_STORE = "truststore-example_com-client";
    private static final String SERVER_KEY_STORE = "keystore-example_com-server";

given trust and key stores are for the example.com hostname instead of the localhost. This is done because most of the connectors work in a way that when default hostname verification is failed, the validation is passed to custom hostname verification if any. However Jetty connector works in the opposite way - when default hostname verification is failed, the flow is finished with an exception without passing validation to a custom hostname verifier. That is why default hostname validation should be disabled and only then custom hostname verifier can be tested.

Regarding the other way around - probably not, because hostnames are not necessarily different - those could be localhost/localhost and all would be fine, the custom hostname verifier would be involved in this case. This particular test actually demonstrates only a corner case for generally invalid hostname vs certificate. But in most cases, default hostname validation would pass.

@jansupol jansupol added this to the 2.39.1 milestone Mar 23, 2023
@senivam senivam merged commit 0914c71 into eclipse-ee4j:master Mar 23, 2023
@senivam senivam deleted the 2x_hostnameVerifier branch March 23, 2023 09:26
This was referenced Mar 23, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JettyConnectorProvider does not support JerseyClientBuilder.hostnameVerifier()?
3 participants