Skip to content
New issue

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

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

Already on GitHub? Sign in 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.

@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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