[jira] [Resolved] (CXF-5818) StackOverflowError caused by HttpsURLConnectionFactory

["Daniel Kulp (JIRA)" <ji...@apache.org>]

     [ 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)