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)
