JDK-8209333 : Socket reset issue for TLS 1.3 socket close
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-08-09
  • Updated: 2021-02-11
  • Resolved: 2018-12-18
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 13 JDK 8 Other
11.0.8-oracleFixed 12 b25Fixed 13Fixed 8u261Fixed openjdk8u292Fixed
Related Reports
Relates :  
Relates :  
Description
After a long time of trying to get the code working I could able to write a logic to reproduce the intermittent failure.

I have tried a lot many times and failure is reproducible every time  with Multithreading .

However , please note  I left a  commented  code in main function, where the logic is looped just in case you don���t see the intermittent failure.

The scenario is for testing ���setNeedClientAuth��� , the scenario is as follows reproducible  with JDKb20

1.	Basic  idea is to get a Client  SSLSocket which is based on an empty keystore , so client has no way to authorize itself.
2.	Create  a SSLServerSocket based on the JKS keystore attached (testkeys.jks) , configure it so that ���setNeedClientAuth��� is false.
3.	Accept the connections from client on a port which is shared with client.
4.	Client thread is started , the SSLSocketFactory is retrieved form a SSLContext which is initialized with an empty keystore ,
SSLSocket is created.
5.	Client  socket is connected to the server on the remote port 
6.	Client sends some data to server
7.	Client closes its socket
8.	Server tries to read the data
9.	Server breaks with SSLException: Software caused connection abort: recv failed

Please find the logs attached with ���javax.net.debug=all��� VM option (SSLSocketHanshakeLogs.txt)

Please find the attached code ���SSLSocketHandshake.java���

**IMPORTANT** :
If in the above order of operations, #7 is omitted, i.e. if the client socket is not closed, then there is NO intermittent  SSLException


Comments
11u Backport RFR approval: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002779.html
13-03-2020

Hi Severin, you are right, it looks as if JDK-8219991 is needed, here, too. I'll check and downport them together.
05-03-2020

[~goetz] This seems to have caused some regressions. JDK-8219658 was the first attempt, then backed out again via JDK-8219990. Then a later fix, JDK-8219991, got developed. Are you planning on backporting JDK-8219991 to OpenJDK 11u as well?
02-03-2020

Fix request (11u) I would like to downport this for parity with 11.0.8-oracle. Applies clean.
28-02-2020

Intermittent issue and cannot reproduce original issue, close as not verified.
30-01-2019

Deferral request approved.
15-08-2018