[
https://issues.apache.org/jira/browse/CXF-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-5818.
------------------------------
Resolution: Fixed
Fix Version/s: 3.0.1
2.7.12
2.6.15
Assignee: Daniel Kulp
> 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
> Assignee: Daniel Kulp
> Fix For: 2.6.15, 2.7.12, 3.0.1
>
>
> 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)
