Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-5818

StackOverflowError caused by HttpsURLConnectionFactory

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.7.10
    • Fix Version/s: 2.6.15, 2.7.12, 3.0.1
    • Component/s: Core
    • Labels:
      None
    • Environment:

      OSX, Solaris, Linux

    • Estimated Complexity:
      Unknown

      Description

      If CFX is configured with the following TLSClientParameters:

      TLSClientParameters tlsClientParameters = new TLSClientParameters();
      tlsClientParameters.setDisableCNCheck(true);
      tlsClientParameters.setKeyManagers(...);
      tlsClientParameters.setTrustManagers(...);
      tlsClientParameters.setCertAlias(...);

      For a new connection, HttpsURLConnectionFactory will create a SocketFactory based on these values, and set the SocketFactory on the connection.

      As part of this, HttpsURLConnectionFactory.decorateWithTLS() attempts to cache the SocketFactory, with the socketFactory being recreated if the hash of the TlsClientParameters differs from the lastTlsHash - the hash from last time the method was called. Creation of the SocketFactory also involves wrapping the TlsClientParameter keyManagers with an AliasedX509ExtendedKeyManager.

      There is a bug where the value of the hash changes after its value is calculated and stored in lastTlsHash. This is because the TLSClientParameters are subsequently modified by getKeyManagersWithCertAlias() by wrapping the keyManagers stored in TLSClientParameters with an AliasedX509ExtendedKeyManager. Since the TLSClientParameters changes internally, the hash changes value too.

      Unfortunately, because the hash changes in this way, every new connection to HttpsURLConnectionFactory results in both a new SocketFactory being created, and also a new AliasedX509ExtendedKeyManager wrapping the keyManagers inside the TLSClientParameters.

      This chain of AliasedX509ExtendedKeyManagers grows to the point where a call to getCertificateChain(), which recursively calls into the chain of wrapped AliasedX509ExtendedKeyManagers, throws a StackOverflowError:

      java.lang.StackOverflowError
      at org.apache.cxf.transport.https.AliasedX509ExtendedKeyManager.getCertificateChain(AliasedX509ExtendedKeyManager.java:92)
      at org.apache.cxf.transport.https.AliasedX509ExtendedKeyManager.getCertificateChain(AliasedX509ExtendedKeyManager.java:92)
      at org.apache.cxf.transport.https.AliasedX509ExtendedKeyManager.getCertificateChain(AliasedX509ExtendedKeyManager.java:92)
      at org.apache.cxf.transport.https.AliasedX509ExtendedKeyManager.getCertificateChain(AliasedX509ExtendedKeyManager.java:92)
      at org.apache.cxf.transport.https.AliasedX509ExtendedKeyManager.getCertificateChain(AliasedX509ExtendedKeyManager.java:92)

      ... lots more!

      The solution may be to move the calculation of the TLSClientParameters lastTlsHash to the end of the getKeyManagersWithCertAlias() method, after the TlsClientParameters keyManagers have been wrapped by the AliasedX509ExtendedKeyManager.

      A work-around is to set the SocketFactory explicitly on TlsClientParameters, in which case HttpsURLConnectionFactory has no need to create a new SocketFactory, and the wrapping of keyManagers by AliasedX509ExtendedKeyManager is never performed.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                dkulp Daniel Kulp
                Reporter:
                tom.magowan Tom Magowan
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: