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: 2022-10-18
  • 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 15 JDK 16 JDK 17 JDK 8 Other
11.0.11-oracleFixed 15.0.10Fixed 16.0.1Fixed 17 b03Fixed 8u281Fixed openjdk8u292Fixed
Related Reports
Duplicate :  
JDK-8258518 - TLS performance degradation after 8u271 upgrade
Relates :  
JDK-8273553 - sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368
Relates :  
JDK-8260923 - Add more tests for SSLSocket input/output shutdown
Description
following exception seen after upgrading to 8u261 (from 8u251)

javax.net.ssl|SEVERE|34|event-queue-vcn-rgn-api:10.241.21.139:9|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)
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk15u-dev/pull/288 Date: 2022-10-18 12:48:07 +0000
18-10-2022
Fix request (15u) I'd like to backport this fix for parity with major releases. Clean backport, security tests run fine.
18-10-2022
A few notes since this was brought up by another issue. The example code which exposed this issue was in Apache HttpClient Core, and used this pattern: try (final Socket socket = socketHolder.getSocket()) { ...deleted... try { try { socket.shutdownOutput(); } catch (final IOException ignore) { } try { socket.shutdownInput(); } catch (final IOException ignore) { } } catch (final UnsupportedOperationException ignore) { // if one isn't supported, the other one isn't either } The issue was subsequently removed by Apache in later releases of 4.4.x/5.0.x/5.1.x/5.2.x: https://issues.apache.org/jira/browse/HTTPCORE-658 https://github.com/apache/httpcomponents-core/commit/f7e876b HTTPCORE-658: removed explicit inbound / outbound socket shutdown from the `#close` method of classic HTTP connections by removing the shutdownInput/Output calls and relied on the try-with-resources for closing. In our previous code, the shutdownInput() triggered a fatal/internal_error call, which sent a fatal alert, and also invalidated the session. This caused performance hits when reconnections would cause full handshakes instead of fast resumptions. Current source: https://github.com/apache/httpcomponents-core/blob/master/httpcore5/src/main/java/org/apache/hc/core5/http/impl/io/BHttpConnectionBase.java
04-03-2022
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.
11-01-2021
jdk16u Fix Request: This fix should help interoperability of TLS applications upgrading from JDK 7/8.
23-12-2020
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
23-12-2020
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.
12-11-2020
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
21-09-2020