Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <2073238854.40571267638987255.JavaMail.jira@brutus.apache.org>
Date: Wed, 3 Mar 2010 17:56:27 +0000 (UTC)
From: "Glen Mazza (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Commented: (CXF-2688) Allow deactivation of SSL X509
 Certificates validation
In-Reply-To: <359234331.44531267485245836.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840763#action_12840763 ] 

Glen Mazza commented on CXF-2688:
---------------------------------

I just need to have this sanity checked by a couple more CXF committers (there's about 25-30 of us, so that should not be too hard).  I do not like this change, but if a couple of others are OK it, it is not worth vetoing.

It is beneficial for a product to be robust enough, to have protective mechanisms so that even if total newbie developers work with it, there is little or no security loss that can occur.  We don't want people's credit card numbers or other sensitive data to be stolen.

The reason for introducing this potential security hole--to help newbies who don't know how to work with self-signed certs--is disconcerting.  How sure can we be that such people indeed will remember to set trustAllCertificates back to "false" for production time?  If they are not going to learn about certs during development how are they going to learn it production time?  Further, should such people who stumble over certificate usage really be programming secure web services to begin with?

Glen


> Allow deactivation of SSL X509 Certificates validation
> ------------------------------------------------------
>
>                 Key: CXF-2688
>                 URL: https://issues.apache.org/jira/browse/CXF-2688
>             Project: CXF
>          Issue Type: New Feature
>          Components: Transports
>    Affects Versions: 2.2.6
>            Reporter: Cyrille Le Clerc
>            Assignee: Cyrille Le Clerc
>             Fix For: 2.2.7
>
>         Attachments: CXF-2688.diff
>
>
> CXF client (JAXWS & JAXRS) for HTTPS calls currently only allows to disable hostname verification ({{<http-conf:tlsClientParameters disableCNCheck="true" />}}) but does not allow to disable X509 certificates checking.
> Due to this, it can be painful to invoke services with self-signed certificates on non-production environments (see sample stacktrace below).
> Here is a proposal to disable all X509 certificates in CXF (JAXWS & JAXRS) clients :
> * Add boolean attribute {{trustAllCertificates}} to {{<http-conf:tlsClientParameters ... />}},
> * In the {{HTTPConduit}}, if {{trustAllCertificates="true"}}, the {{HttpsURLConnectionFactory}} will use an 'accept all certificates' {{javax.net.ssl.X509TrustManager}} and an 'accept all' {{javax.net.ssl.HostnameVerifier}}.
> *Note* : this proposal adds an attribute {{trustAllCertificates}} to the {{TLSClientParametersType}} complex type and thus *this proposal requires to publish a new 'backward compatible' [http://cxf.apache.org/schemas/configuration/security.xsd]*. 
> Configuration sample enabling 'trustAllCertificates' to invoke an HTTPS service:
> {code:xml}
> <jaxws:client id="helloWorldServiceClient"
>    serviceClass="com.example.HelloWorldService"
>    address="https://example.com/services/helloWorldService">
> </jaxws:client>
> <http-conf:conduit name="{http://example.com/}HelloWorldServicePort.http-conduit">
>    <!-- trust all certificates (self signed certificates, etc) -->
>    <http-conf:tlsClientParameters trustAllCertificates="true" />
>    
>    <http-conf:authorization>
>       <security:UserName>my-user-name</security:UserName>
>       <security:Password>my-password</security:Password>
>    </http-conf:authorization>
> </http-conf:conduit>
> {code}
> CXF client exception's stacktrace with a self-signe certificate: 
> {noformat}
> 2010/03/01 22:05:23,682  WARN [http-8080-1] org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for 
> {http://example.com/}HelloWorldServiceService#{http://example.com/}sayHi has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Could not send Message.
> 	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
> 	...
> 	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> 	at $Proxy69.sayHi(Unknown Source)
> 	...
> Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
> 	...
> Caused by: sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
> 	...
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
> 	...
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.