[
https://issues.apache.org/jira/browse/HTTPCLIENT-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810427#comment-17810427
]
Oleg Kalnichevski commented on HTTPCLIENT-2134:
-----------------------------------------------
[~peter.dettman] [~m_v_egorov] I was looking into HTTPCLIENT-2151 and concluded
that in order to be able to work on this new feature I needed a reasonable test
case. I went back to the original issue and was not able to reproduce it or
make any sense of what the problem actually was.
Please note I used just the core transport components simply because the core
has fewer levels of complexity on top of straight JSSE.
The ` sslParameters.setEndpointIdentificationAlgorithm("HTTPS")` line appears
to have no effect. I get pretty much identical TLS handshake (at least judging
by the TLS debug log output). I have not tried looking at the TLS packets with
WireShark yet. I need to know if the issue still valid before I do that.
I need a reasonable test case for HTTPCLIENT-2151 to proceed,
Oleg
{code:java}
final HttpRequester httpRequester = RequesterBootstrap.bootstrap()
.setSslSetupHandler(sslParameters -> {
sslParameters.setEndpointIdentificationAlgorithm("HTTPS"); // This
line does not seem to have any effect
sslParameters.setProtocols(new String[] {TLS.V_1_2.id});
})
.create();
final HttpHost target = new HttpHost("https", "sso.rbo.raiffeisen.ru");
final HttpCoreContext coreContext = HttpCoreContext.create();
final ClassicHttpRequest request = ClassicRequestBuilder.get()
.setPath("/")
.build();
try (ClassicHttpResponse response = httpRequester.execute(target, request,
Timeout.ofSeconds(5), coreContext)) {
System.out.println(request.getUri() + "->" + response.getCode());
System.out.println("==============");
}
TimeUnit.SECONDS.sleep(1);
httpRequester.closeIdle(TimeValue.ZERO_MILLISECONDS);
try (ClassicHttpResponse response = httpRequester.execute(target, request,
Timeout.ofSeconds(5), coreContext)) {
System.out.println(request.getUri() + "->" + response.getCode());
System.out.println("==============");
}
{code}
> HttpClient doesn't reuse TLS 1.2 Session
> ----------------------------------------
>
> Key: HTTPCLIENT-2134
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2134
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
> Affects Versions: 4.5.13, 5.0.3
> Reporter: Maxim Egorov
> Priority: Minor
> Labels: volunteers-wanted
> Attachments: TestApacheHttpClientApp.java, handshake.log
>
>
> To reproduce run on java 11+:
> java -cp ... -Djavax.net.debug=ssl:handshake TestApacheHttpClientApp
> As you can see from handshake.log file HttpClient always create new tls
> session.
> The root of problem is support of Extended Master Key Extension in
> [https://github.com/openjdk/jdk/blob/jdk-11+28/src/java.base/share/classes/sun/security/ssl/ClientHello.java#L497.]
> The standard jdk HttpURLConnection doesn't be affected this issues because
> of it sets chc.sslConfig.identificationProtocol equals to HTTPS by default
> [https://github.com/openjdk/jdk/blob/jdk-11%2B28/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java#L560.]
> I tried to repeat the same trick (The commented code), but due to the bugs
> of JDK [https://bugs.openjdk.java.net/browse/JDK-8253368] and may be
> incorrect implementation of method
> org.apache.http.impl.BHttpConnectionBase.close it doesn't work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
