JDK-8240871 : SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version:
    openjdk8u272,11.0.2,11.0.5-oracle,13.0.1,14 openjdk8u272,11.0.2,11.0.5-oracle,13.0.1,14
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: x86_64
  • Submitted: 2020-03-11
  • Updated: 2021-03-01
  • Resolved: 2020-05-29
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 15
15 b26Fixed
Related Reports
Cloners :  
JDK-8233619 - SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3
Description
This was originally raised as an issue against Apache Tomcat:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892

Reproduction steps with Tomcat (including key stores and Tomcat configuration) are in that report. The summary is:
- Java 13.0.1+9
- Tomcat 9 latest release (or latest source)
- TLSv1.3
- client authentication required
- Firefox client in private browsing mode

Debugging of the TLS handshake in Tomcat (https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/net/SecureNioChannel.java#L169) shows that in private browsing mode the penultimate SSLEngine handshake status is NEED_TASK.
There is a single task containing 3 entries in the DelegatedAction map.
The final entry in that Map ends up in T13FinishedConsumer which in turn leads to...
TransportContext.finishHandshake(). While this method returns HandshakeStatus.FINISHED, the return value is ignored. As soon as that method sets handshakeContext=null, the SSLEngine handshake status is NOT_HANDSHAKING. This breaks Tomcat's TLS handshake code as Tomcat expects the SSLEngine handshake status to be FINISHED.

When Firefox is used in non-private browsing mode the penultimate SSLEngine handshake status is NEED_WRAP which becomes FINISHED after the write.
Comments
Marking it as verified based on comments from [~markt]
02-06-2020
Fix confirmed with the original Tomcat test case and a JDK built from source.
02-06-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/33613fd1bcc6 User: xuelei Date: 2020-05-29 20:48:27 +0000
29-05-2020
Here is the code review thread: https://mail.openjdk.java.net/pipermail/security-dev/2020-April/021729.html The update could be confirmed with Tomcat and Firefox in private mode, as described in the bug description. As this case happens only when psk_key_exchange_modes does not present, which is not a behavior supported by JDK, I did not find a workaround for a new regression test yet. I added the labels, noreg-external and noreg-hard.
30-04-2020
Cause known: in JDK-8233619, the FINISHED status is present if there is new session ticket post-handshake message. Private-mode Firefox does not support session resumption and then there is no post-handshake new session ticket message. After the delegated task, getHandshakeStatus cannot use FINISHED per the spec. It's a tricky case now.
28-04-2020
I have retested the original Tomcat reproduction steps described in the issue description with OpenJDK 15 ea13 and it still fails.
11-03-2020