JDK-8253368 : TLS connection always receives close_notify exception
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 8u261
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-09-18
  • Updated: 2021-04-12
  • Resolved: 2020-12-23
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 16 JDK 17 JDK 8 Other
11.0.11Fixed 16.0.1Fixed 17 b03Fixed 8u281Fixed openjdk8u292Fixed
Related Reports
Duplicate :  
Relates :  
following exception seen after upgrading to 8u261 (from 8u251)

javax.net.ssl|SEVERE|34|event-queue-vcn-rgn-api:|2020-09-02 02:20:14.290 UTC|TransportContext.java:319|Fatal (INTERNAL_ERROR): closing inbound before receiving peer's close_notify (
"throwable" : {
  javax.net.ssl.SSLException: closing inbound before receiving peer's close_notify
  	at sun.security.ssl.Alert.createSSLException(Alert.java:133)
  	at sun.security.ssl.Alert.createSSLException(Alert.java:117)
  	at sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
  	at sun.security.ssl.TransportContext.fatal(TransportContext.java:270)
  	at sun.security.ssl.TransportContext.fatal(TransportContext.java:261)
  	at sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:656)
  	at sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:635)
  	at org.apache.http.impl.BHttpConnectionBase.close(BHttpConnectionBase.java:325)
  	at org.apache.http.impl.conn.CPoolEntry.closeConnection(CPoolEntry.java:70)
  	at org.apache.http.impl.conn.CPoolProxy.close(CPoolProxy.java:86)
  	at org.apache.http.impl.execchain.ConnectionHolder.releaseConnection(ConnectionHolder.java:103)
  	at org.apache.http.impl.execchain.ConnectionHolder.close(ConnectionHolder.java:156)
  	at org.apache.http.impl.execchain.HttpResponseProxy.close(HttpResponseProxy.java:62)
  	at com.oracle.pic.commons.client.http.OracleApacheConnector$2.close(OracleApacheConnector.java:482)
  	at java.io.FilterInputStream.close(FilterInputStream.java:181)
Fix Request (OpenJDK 11u): Please approve backporting this to OpenJDK 11u. Seems Oracle backported it too. The JDK 17 patch applies clean. Test fails on unpatched OpenJDK 11u and passes after. Testing: :jdk_security. Fixes a regression.

jdk16u Fix Request: This fix should help interoperability of TLS applications upgrading from JDK 7/8.

Changeset: a4e082e9 Author: Sean Coffey <coffeys@openjdk.org> Date: 2020-12-23 12:26:44 +0000 URL: https://git.openjdk.java.net/jdk/commit/a4e082e9

I don't believe the JDK should be checking for or throwing such an error when the input side of socket is being closed. Relevant sections from TLSv1.2 and v1.3 RFCs pasted here for reference: TLSv1.3 RFC https://tools.ietf.org/html/rfc8446#section-6.1 Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation. TLSv1.2 RFC https://tools.ietf.org/html/rfc5246#section-7.2.1 It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection.

Submitter using TLSv1.2 protocol. The app is closing outbound of SSLSocket and writes out a TLS close_notify alert. It then goes to close inbound of SSLSocket but the JDK libraries now throw a fatal exception: "Fatal (INTERNAL_ERROR): closing inbound before receiving peer's close_notify" [1] Reading the TLSv1.2 spec at https://tools.ietf.org/html/rfc5246 - section 7.2.1 > Unless some other fatal alert has been transmitted, each party is > required to send a close_notify alert before closing the write side > of the connection. The other party MUST respond with a close_notify > alert of its own and close down the connection immediately, > discarding any pending writes.*It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection.* After reading that, I'm wondering if the JDK should really be throwing a fatal alert. Further investigation needed