Under certain conditions when using TLS 1.3 and JDK11, an infinite loop can occur during handshaking (until it times out anyway).
This appears to be in some way related to the behaviour of TLS 1.3 not requiring a closeNotify to be sent (the issue disappears when the system property to bring back the old behaviour is active).
Following the logic of the unwrapAll method and the output of the log, it appears to occur when trying to gracefully terminate the SSL connection - I'm not really sure why it's trying to handshake to close a connection but that's a separate issue and likely just a gap in my knowledge.
The flow of things goes as follows:
Websocket connection gets established, following a successful handshake
It receives some further data and goes into SSLBaseFilter.handleRead -> SSLBaseFilter.unwrapAll (I believe line 293, since the next log messages are to with unwrap rather than doHandshakeStep)
Enter the unwrapAll loop
First unwrap returns: Status = OK HandshakeStatus = NOT_HANDSHAKING
Since it’s not handshaking and there is no error, it skips the handshaking block (lines 408-420) enters the switch at line 422, see’s that the response is OK and that there is some input remaining as it only breaks the switch rather than the whole do while (line 424)
Second unwrap returns: Status = CLOSED HandshakeStatus = NEED_WRAP
Since it is now apparently handshaking, passes the check at line 408, and as the status is CLOSED goes to execute the silentRehandshake method.
The silentRehandshake attempts to perform a handshake via doHandshakeSync, specifically line 576/577, before it enters the do while loop at line 579.
Since the handshake status is NEED_WRAP it attempts to wrap (line 668) and gets a result of Status = OK HandshakeStatus = NEED_WRAP
Without my change, it then loops on this until the handshake timeout expires, never returning to doHandshakeSync (line 576/577)
Presumably the other side has closed the connection but hasn't sent a closeNotify, causing this side (Payara in this case) to continually attempt to handshake with it on a no longer active connection. Again, I'm not clear on how the current graceful SSL connection termination is meant to work and why handshaking is a part of this, but this added change appears to work (even if it is a bit brutal in essentially killing the connection dead) - more graceful solutions are likely available.
Example log for reference (line numbers may be slightly off in a couple of places due to Payara having a few unsynced changes):
Under certain conditions when using TLS 1.3 and JDK11, an infinite loop can occur during handshaking (until it times out anyway). This appears to be in some way related to the behaviour of TLS 1.3 not requiring a closeNotify to be sent (the issue disappears when the system property to bring back the old behaviour is active).
Following the logic of the unwrapAll method and the output of the log, it appears to occur when trying to gracefully terminate the SSL connection - I'm not really sure why it's trying to handshake to close a connection but that's a separate issue and likely just a gap in my knowledge.
The flow of things goes as follows:
SSLBaseFilter.handleRead
->SSLBaseFilter.unwrapAll
(I believe line 293, since the next log messages are to withunwrap
rather thandoHandshakeStep
)unwrapAll
loopStatus = OK HandshakeStatus = NOT_HANDSHAKING
Status = CLOSED HandshakeStatus = NEED_WRAP
silentRehandshake
method.doHandshakeSync
, specifically line 576/577, before it enters the do while loop at line 579.Status = OK HandshakeStatus = NEED_WRAP
doHandshakeSync
(line 576/577)Presumably the other side has closed the connection but hasn't sent a closeNotify, causing this side (Payara in this case) to continually attempt to handshake with it on a no longer active connection. Again, I'm not clear on how the current graceful SSL connection termination is meant to work and why handshaking is a part of this, but this added change appears to work (even if it is a bit brutal in essentially killing the connection dead) - more graceful solutions are likely available.
Example log for reference (line numbers may be slightly off in a couple of places due to Payara having a few unsynced changes):
Signed-off-by: Andrew Pielage pandrex247@hotmail.com