JDK-8212885 : TLS 1.3 resumed session does not retain peer certificate chain
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 8,11,12
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-10-23
  • Updated: 2020-12-07
  • Resolved: 2018-11-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 8 Other
11.0.3-oracleFixed 12 b20Fixed 8u261Fixed openjdk8u272Fixed
Related Reports
Duplicate :  
JDK-8220723 - SSLSession.getPeerCertificates() throws SSLPeerUnverifiedException if a pre_shared_key was used
Relates :  
JDK-8215933 - TLS Session Resumption loses track of SSLSession values
Description
TLS 1.3 resumed sessions are not preserving the peer certificate chain that is held in the initial SSLSession object created from the initial handshake.  The SSLSession object pulled from the resumed session will throw SSLPeerUnverifiedException when SSLSession.getPeerCertificates() or SSLSession.getPeerPrincipal() methods are invoked.
Comments
Fix Request: clean backport https://cr.openjdk.java.net/~martin/webrevs/jdk11/JDK-8212885-backport/
28-01-2019
Can I ask if this will be backported to jdk11u please? thanks
19-11-2018
I stand corrected. The change that I made in PreSharedKeyExtension actually does affect the decision by the server to resume a handshake if client authentication was negotiated in the initial handshake. Before the fix, when client authentication was used initially, the resumed client hello would attempt to pull the peer principal from the new session. That would always fail and result in the canRejoin() method always returning false. So resumption should never have worked in this particular scenario - it would do a full handshake instead I believe. The fix took care of that problem so the getPeerPrinicipal call would work, and canRejoin checks could proceed normally.
13-11-2018
Testing with JSSE server and OpenSSL client 1. Resumption with client auth failed on JDK 12+18, please see attached server-resumption-clientauth-failed.log. 2. This same case passed with your webrev [1], please see attached server-resumption-clientauth-passed.log. [1] http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.03/
12-11-2018
No, it shouldn't. The resumption handshake messages don't include CertificateRequest and Client certificate messages. If the client had previously asserted the post_handshake_auth extension. In that case, the CertificateRequest consumer would get run and certificate selection on the client should take place in a similar fashion to how it happens in an initial handshake. This bug addresses the setting of the certificates used in authentication in the SSLSession field, but makes no changes to how those certificates are put in the handshake context fields, which would have a more direct impact to handshake processing.
12-11-2018
Does that mean this issue affects resumption with client authentication?
12-11-2018
This solution should also allow us to move the solution for JDK-8211806 into this new copy constructor.
30-10-2018
In a TLS 1.3 connection, NewSessionTicket consumption creates a new handshake session. Currently that session is built from a PostHandshakeContext that does not carry all the same field information that the handshake contexts used in the initial handshake carry. The proposed solution is to create the resumed session object using a copy constructor, changing only the relevant fields that would differ in its initial state, such as session ID. Negotiation messages during the actual resumption should then further modify the SSLSessionImpl object if needed.
30-10-2018