cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CXF-5818) StackOverflowError caused by HttpsURLConnectionFactory
Date Tue, 01 Jul 2014 19:51:24 GMT

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

Mime
View raw message