[
https://issues.apache.org/jira/browse/CXF-8952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Violet updated CXF-8952:
----------------------------------
Description:
*HttpClientHTTPConduit* does't have support for TLSv1.3 out of the box. [Look
at line #253
here|https://github.com/apache/cxf/blob/ee4244116cb49c007bde3ee7ee6a06a4cfb26027/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpClientHTTPConduit.java#L253].
!image-2023-10-30-17-30-19-307.png|width=821,height=227!
This means that any endpoint which solely supports *TLSv1.3* and has turned
off other lower protocols will fail SSL Handshake.
One can pass in a singular {*}secureSocketProtocol{*}, but that doesn't support
passing in a list for negotiation fallback.
I.e. We can do the following:
{code:java}
ClientConfiguration config = WebClient.getConfig(service);
final TLSClientParameters tlsClientParameters =
ObjectUtils.firstNonNull(config.getHttpConduit().getTlsClientParameters(), new
TLSClientParameters());
tlsClientParameters.setSecureSocketProtocol("TLSv1.3");
{code}
However, this will not work with endpoints that do now support {*}TLSv1.3{*};
it works great for endpoints that only have *TLSv1.3* though.
{*}Solution{*}:
{*}Option 1{*}({color:#FF0000}Ideal; *recommended*{color}): Add *TLSv1.3* to
the list of protocols when creating the HttpClient through the builder.
{*}Option 2{*}: Allow *setSecureSocketProtocol* to take in an *array* of
protocols.
was:
When processing requests using the JAX RS client which used the new HttpClient,
there is the input stream is closed prematurely.
[^CXF-HTTPClient-LargePayload.zip] , you will see that we are using
{*}Response{*}, because we are interested in getting response status as well as
the response headers. This fails with the following error:
{code:java}
Exception in thread "main" java.lang.RuntimeException: java.io.IOException:
closed
at LargeDataTester.main(LargeDataTester.java:89)
Caused by: java.io.IOException: closed
at
java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.current(ResponseSubscribers.java:448)
at
java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.read(ResponseSubscribers.java:508)
at java.base/java.io.FilterInputStream.read(FilterInputStream.java:119)
at
org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientFilteredInputStream.read(HttpClientHTTPConduit.java:422)
at java.base/java.io.SequenceInputStream.read(SequenceInputStream.java:197)
at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:333)
at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:376)
at java.base/sun.nio.cs.StreamDecoder.lockedRead(StreamDecoder.java:219)
at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:173)
at java.base/java.io.InputStreamReader.read(InputStreamReader.java:189)
at java.base/java.io.Reader.read(Reader.java:265)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1610)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1589)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:1384)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:1153)
at org.apache.commons.io.IOUtils.toString(IOUtils.java:3105)
at LargeDataTester.main(LargeDataTester.java:84)
Caused by: java.io.IOException: selector manager closed
at
java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.selectorClosedException(HttpClientImpl.java:1061)
at
java.net.http/jdk.internal.net.http.HttpClientImpl.closeSubscribers(HttpClientImpl.java:552)
at
java.net.http/jdk.internal.net.http.HttpClientImpl.stop(HttpClientImpl.java:543)
at
java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.shutdown(HttpClientImpl.java:1165)
at
java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1364)
{code}
{color:#FF0000}*You can execute the code like so:*{color}
{code:java}
mvn compile exec:exec{code}
ℹ️ {*}Note{*}: You can do a diff between what works(Letting CXF deserialize the
object response payload automatically), and the last commit(Using Response).
{code:java}
git diff HEAD^ HEAD {code}
> HttpClientHTTPConduit in CXF doesn't support TLSv1.3 along with other
> protocols
> -------------------------------------------------------------------------------
>
> Key: CXF-8952
> URL: https://issues.apache.org/jira/browse/CXF-8952
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 4.0.3, 4.0.4
> Reporter: Sebastian Violet
> Assignee: Daniel Kulp
> Priority: Critical
> Fix For: 3.6.3, 4.0.4
>
> Attachments: image-2023-10-30-17-30-19-307.png
>
>
> *HttpClientHTTPConduit* does't have support for TLSv1.3 out of the box.
> [Look at line #253
> here|https://github.com/apache/cxf/blob/ee4244116cb49c007bde3ee7ee6a06a4cfb26027/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpClientHTTPConduit.java#L253].
> !image-2023-10-30-17-30-19-307.png|width=821,height=227!
> This means that any endpoint which solely supports *TLSv1.3* and has turned
> off other lower protocols will fail SSL Handshake.
> One can pass in a singular {*}secureSocketProtocol{*}, but that doesn't
> support passing in a list for negotiation fallback.
> I.e. We can do the following:
> {code:java}
> ClientConfiguration config = WebClient.getConfig(service);
> final TLSClientParameters tlsClientParameters =
> ObjectUtils.firstNonNull(config.getHttpConduit().getTlsClientParameters(),
> new TLSClientParameters());
> tlsClientParameters.setSecureSocketProtocol("TLSv1.3");
> {code}
> However, this will not work with endpoints that do now support {*}TLSv1.3{*};
> it works great for endpoints that only have *TLSv1.3* though.
>
> {*}Solution{*}:
> {*}Option 1{*}({color:#FF0000}Ideal; *recommended*{color}): Add *TLSv1.3* to
> the list of protocols when creating the HttpClient through the builder.
> {*}Option 2{*}: Allow *setSecureSocketProtocol* to take in an *array* of
> protocols.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
