Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 24 Jun 2014 11:37:24 +0000 (UTC)
From: "Tom Magowan (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12723336.1403609756621.36536.1403609844264@arcas>
In-Reply-To: <JIRA.12723336.1403609756621@arcas>
References: <JIRA.12723336.1403609756621@arcas>
Subject: [jira] [Created] (CXF-5818) StackOverflowError caused by
 HttpsURLConnectionFactory
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Tom Magowan created CXF-5818:
--------------------------------

             Summary: StackOverflowError caused by HttpsURLConnectionFactory
                 Key: CXF-5818
                 URL: https://issues.apache.org/jira/browse/CXF-5818
             Project: CXF
          Issue Type: Bug
          Components: Core
    Affects Versions: 2.7.10
         Environment: OSX, Solaris, Linux
            Reporter: Tom Magowan


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.


--
This message was sent by Atlassian JIRA
(v6.2#6252)