[
https://issues.apache.org/jira/browse/HTTPCLIENT-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17319340#comment-17319340
]
Peter Dettman commented on HTTPCLIENT-2134:
-------------------------------------------
[RFC 7627|https://tools.ietf.org/html/rfc7627] introduced the
_extended_master_secret_ TLS extension. A reasonable rule-of-thumb from that
RFC is that sessions which did not negotiate _extended_master_secret_ during
the initial handshake should not be used for subsequent abbreviated handshakes
(i.e. session resumption). Note that this issue is moot from TLS 1.3 onwards
because extended_master_secret is intrinsic (i.e. always effectively on).
SunJSSE has more complicated rules and settings that mean such a session might
under some circumstances be resumed. For the most part these are not within the
scope of HttpClient, but controlled with system or security properties. The
possible exception I can see is endpoint identification. Since Java 1.7, JSSE
has integrated support for HTTPS endpoint identification (enabled using
[SSLParameters.setEndpointIdentificationAlgorithm|https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLParameters.html#setEndpointIdentificationAlgorithm-java.lang.String-]).
One of its rules for whether resumption is allowed relies on knowing that
endpoint identification has been enabled in this way, which it cannot otherwise
determine from an arbitrary HostnameVerifier callback.
I believe that a user could already switch to the JSSE integrated endpoint
identification by configuring a custom SSLSocketFactory (and presumably using
to a no-op HostnameVerifier to avoid duplicate effort). Perhaps some sort of
"EndpointIdentificationPolicy" could be considered to make this simpler. Apart
from that possibility, I agree with [~olegk] that there's nothing to be done in
HttpClient.
> 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.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
