Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8282600

SSLSocketImpl should not use user_canceled workaround when not necessary

XMLWordPrintable

        When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1])

        As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].)

        This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... )

        I also ran jdk_security tests locally, which passed for me.

        [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473
        [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1
        [3]
        jdk/src/java.base/share/classes/sun/security/ssl/Alert.java

        Line 243 in b6c35ae
         if (alert == Alert.CLOSE_NOTIFY) {

              sgehwolf Severin Gehwolf
              sgehwolf Severin Gehwolf
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: