cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Magowan (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CXF-5818) StackOverflowError caused by HttpsURLConnectionFactory
Date Tue, 24 Jun 2014 11:37:24 GMT
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)

Mime
View raw message