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

REGRESSION - 6u29 breaks ssl connectivity using TLS_DH_anon_WITH_AES_128_CBC_SHA

XMLWordPrintable

    • b12
    • x86
    • solaris_8, windows_xp, windows_2008, windows_7

        FULL PRODUCT VERSION :
        On the server:

        Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
        Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)

        On the client:

        Java versino "1.6.0_29"
        Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
        Java HotSpot(TM) 64-bit Server VM (build 20.4-b02, mixed-mode)

        ADDITIONAL OS VERSION INFORMATION :
        On the server:
        # uname -a
        Linux squid 2.6.26-2-amd64 #1 SMP Mon Jun 13 16:29:33 UTC 2011 x86_64 GNU/Linux

        On the client: Windows 7 Ultimate

        A DESCRIPTION OF THE PROBLEM :
        System was working fine with server and client on Java 6 versions before 6u29 (e.g., 6u27). The server and client didn't need to be java version lock-stepped either.

        A customer upgraded their client Windows 7 PC to 6u29 and communications between the client and server immediately fails. I was able to duplicate this field issue in our development lab by updating a client to 6u29.

        Client and server currently communicate via a SSL socket using:

        TLS_DH_anon_WITH_AES_128_CBC_SHA

        If I change the SSL socket to use:

        SSL_DH_anon_WITH_RC4_128_MD5

        Communications between client and server work again. But I have hundreds of customers and to change to this much less secure specification is not viable.

        Upgrading the server to 6u29 also doesn't help the situation. With client and server both on 6u29, failures still happen.

        This breakage may be related to the work done in 6u29 for CVE-2011-3389.

        REGRESSION. Last worked in version 6u26

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        Establish a SSL connection using the TLS_DH_anon_WITH_AES_128_CBC_SHA specification and it will fail after a small number of message exchanges. In our case, a server write, a client write, a server write followed by a consistently failing client write. All writes are externalized Java String or Long objects.

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        They work
        ACTUAL -
        Exceptions:

        On the server:

        java.net.SocketException: Socket closed
        java.net.SocketException: Socket closed
          at java.net.PlainSocketImpl.socketAccept(Native Method)
          at java.net.PlainSocketImpl.accept(Unknown Source)
          at java.net.ServerSocket.implAccept(Unknown Source)
          at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(Unknown Source)
          at com.example.package.ClientConnectionInterface$ServerSocketHandler.run(ClientConnectionInterface.java:681)

        And on the client:

        javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkWrite(Unknown Source)
        at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)
        at java.io.ObjectOutputStream$BlockDataOutputStream.drain(Unknown Source)
        at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(Unknown Source)
        at java.io.ObjectOutputStream.writeFatalException(Unknown Source)
        at java.io.ObjectOutputStream.writeObject(Unknown Source)
        at com.example.package.PrioritySocketManager.initialize(PrioritySocketManager.java:408)
        at com.example.package.connectToSPM(SCAI.java:1224)
        at com.example.package.connect(SCAI.java:533)
        at com.example.package.ConnectionAdapter.establishConnection(ConnectionAdapter.java:283)
        at com.example.package.ConnectionHandler.fullLogin(ConnectionHandler.java:446)
        at com.example.package.ConnectionHandler.access$1200(ConnectionHandler.java:67)
        at com.example.package.ConnectionHandler$3.run(ConnectionHandler.java:299)
        Caused by: javax.net.ssl.SSLException: java.lang.IndexOutOfBoundsException
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Unknown Source)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Unknown Source)
        at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)
        at java.io.ObjectOutputStream$BlockDataOutputStream.write(Unknown Source)
        at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
        at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
        at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
        at java.io.ObjectOutputStream.writeObject0(Unknown Source)
        ... 8 more
        Caused by: java.lang.IndexOutOfBoundsException
        at java.io.ByteArrayOutputStream.write(Unknown Source)
        ... 14 more

        ERROR MESSAGES/STACK TRACES THAT OCCUR :
        See exceptions above

        REPRODUCIBILITY :
        This bug can be reproduced always.

        CUSTOMER SUBMITTED WORKAROUND :
        Change the SSL specification to SSL_DH_anon_WITH_RC4_128_MD5 (others may also work).

              robm Robert Mckenna
              webbuggrp Webbug Group
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: