Summary

Modify the SunJSSE implementation of the SSLSocket shutdownInput() method to not send a fatal alert to the peer and to not invalidate the TLS session if the SSLSocket hasn't received a close notification message from its peer.

Problem

[This is a retroactive CSR for an issue which didn't go through the CSR process. A request to log one retrospectively has been made]

The old SunJSSE implementation of the SSLSocket.shutdownInput() method caused a fatal TLS alert to be generated and sent if the peer socket hadn't sent a close_notify message. This behavior was overly strict and not necessary according to the TLS RFCs. (see https://tools.ietf.org/html/rfc5246 - section 7.2.1)

Creating a fatal alert in such scenarios also has a performance impact given that the TLS session is invalidated.

Solution

If an application tries to close the input stream of an SSLSocket (via shutdownInput() method) without having received a close notification message from its peer, the SSLSocket will no longer:

1. trigger the transmission of a TLS fatal-level alert to the peer, and
2. invalidate the current TLS session.

The new behavior will still consider this condition an error and will throw a local javax.net.ssl.SSLException. A fatal-level alert will no longer be sent to the peer, and the underlying session will remain valid.

In addition, the internal transport context for the SSLSocket will also now be closed. Previously, this step didn't occur if a fatal message was generated.

Specification

There are no API changes. The patch for this change can be viewed via:

https://github.com/openjdk/jdk/commit/a4e082e9