RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3

[Anthony Scarpino]

On 4/30/20 10:19 AM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed:
>      http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/
> 
> For TLS 1.3 full handshake, if the last handshake flight wraps the 
> Finished together with other handshake message, for example client 
> certificate, the flight could be wrapped and encrypted in one record and 
> delegated tasks would be used.  There is no chance to return FINISHED 
> handshake status with SSLEngine.(un)wrap(). However, per the 
> HandshakeStatus.FINISHED specification, this handshake status is only 
> generated by a call to SSLEngine.wrap()/unwrap() and it is never 
> generated by SSLEngine.getHandshakeStatus().
> 
> In order to workaround this case for TLS 1.3, the FINISHED status could 
> present with SSLEngine.wrap() while delivering of the NewSessionTicket 
> post-handshake message.  If this post-handshake message is not needed, a 
> follow-on SSLEngine.wrap() should be called to indicate the FINISHED 
> handshake status.  Although this special SSLEngine.wrap() should not 
> consume or produce any application or network data.
> 
> I also clean up some debug log, names and code style a little bit.
> 
> 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.
> 
> Thanks,
> Xuelei

I do not fully understand the situation, mostly because of SSLEngine 
semantics.  In normal operation, does is HandshakeStatus.FINISHED 
returned when Finished is received or after the NewSessionTicket 
message?  My understanding would have been after Finished because NST is 
suppose to be a post handshake message.  So in this case there is no 
problem, correct?

I'm trying to figure out why you need an empty NST.  Is the problem when 
a number of messages are bundled together.  For example, the Finished 
message with a partial NST, then Finished isn't processed and both sides 
are waiting?  Or do both sides continue normal traffic, it's jut the 
HandshakeStatus.FINISHED is one operation behind?


One code comment so far:
433:  The debug message purpose was to say the NST is a stateless ticket 
and not a preshared key.  Can we keep "stateless" in the message?

Tony