rest icon indicating copy to clipboard operation
rest copied to clipboard

Default behavior of a JAX-RS client regarding HTTPS?

Open oliviercailloux opened this issue 4 years ago • 4 comments

Consider the following code as an example.

ClientBuilder.newBuilder().build().target("https://www.oracle.com/java/technologies/naming-conventions.html").request().get();

I can’t find in the spec how the client is supposed to behave when connecting to an HTTPS URL with a “default” security setting, that is, when I do not explicitly set an SSLContext (as in this example). The documentation is very scarce on that subject, unless I missed something.

  • The JAX-RS standard does not mention anything at all about the HTTPS scheme or TLS or SSL encryption, neither in the Jakarta RESTful Web Services document, nor in the JSR 370 (JAX-RS 2.1, Final) document.
  • ClientBuilder#trustStore​ indicates: “In case a custom trust store or custom SSL context is not specified, the trust management will be configured to use the default Java runtime settings.”
  • ClientBuilder#sslContext indicates: “Set the SSL context that will be used when creating secured transport connections to server endpoints from web targets created by the client instance that is using this SSL context.” Unfortunately, it does not further specify when exactly is the client supposed to create “secured transport connections”. I thought it was fair to assume that this is exactly in cases mandated by the scheme used (ftps, https, …). But I may be wrong.
  • Client#getSslContext() unfortunately leaves it unspecified (in my understanding) what exactly should be returned by default, that is, when the ClientBuilder was not given an explicit ssl context.

I expected that a JAX-RS client would, by default, try to connect using simple HTTP when given an HTTP URL, and using the standard TLS-over-HTTP protocol when given an HTTPS URL, using the Default SSLContext (which I can’t find documentation about but I assume does something reasonable boiling down to accepting Oracle’s certificate and connecting seamlessly, in my example).

On the contrary, it seems from a discussion in a Jersey issue that, in my example, the client (sometimes?) tries to connect using simple HTTP even though it is given a URL with an HTTPS scheme. Is this correct? If so, isn’t this quite unexpected and possibly insecure?

Please consider providing clarifications in the specifications about the behavior a client should exhibit when not configured explicitly with an SSLContext.

Sorry if I missed anything obvious…

oliviercailloux avatar Apr 20 '21 16:04 oliviercailloux

In my view it would be reasonable to assume that SSLContext.getDefault() is used by default. And I guess that this is what the spec means with "default Java runtime settings". At least in my opinion.

chkal avatar Apr 21 '21 06:04 chkal

In my view it would be reasonable to assume that SSLContext.getDefault() is used by default.

I suggest to add this doc to ClientBuilder.

I also think the spec should explicitly mention somewhere that the SSL context (used when creating secured transport connections, as mentioned in ClientBuilder#sslContext) is used if and only if the scheme is ftps or https, if this is the intent. Or specify more vaguely that it depends on the URL scheme and that https and ftps require to use the SSL context and other schemes may or may not use it, depending on the implementation. Or something similar.

Finally, I think it would be nice to define somewhere what the Default SSLContext is supposed to be, although I am not sure that the JAX-RS spec would be the right place for this. If this is already defined somewhere, please consider linking from the JAX-RS spec to that place.

oliviercailloux avatar May 14 '21 05:05 oliviercailloux

@oliviercailloux I'm all for clarifications. Are you interested in providing a PR that includes clarification text about SSL? It can be Javadoc, spec or both.

spericas avatar May 17 '21 14:05 spericas

I don’t think it’s just about clarifications. I suspect some investigations and decisions have to be made, as described in my previous comment.

oliviercailloux avatar Oct 23 '21 16:10 oliviercailloux