cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Mazza (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-2688) Allow deactivation of SSL X509 Certificates validation
Date Thu, 04 Mar 2010 02:51:27 GMT

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

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

Thanks, Cyrille, error message #1 makes sense, but error message #2 may not be necessary--if
the certificate is untrusted, the standard Sun "unable to find valid certification path to
requested target" warning should be sufficient--Googling that error message will return thousands
of hits explaining to anyone what the problem is.  

(I'm confused though about error message #2--this message should never occur anyway if trustAllCertificates=true
because by definition nothing is untrusted, so I don't see how that error message would provide
adequate warning because it would never appear.)

Still, I don't see a rush on this change--it can wait.  (I've been on this team for over two
years and this is first call I've seen for this.)  To play it safe, I would still like to
see a couple of other committers OK this as a sanity check--you can make a posting on CXF-DEV
mailing list to get it.

I don't mind security overrides for those who really know what they are doing (e.g., a Progress
employee for a customer need)--in this case, those error messages would be sufficient.  It's
just when you put a security hole in to help a newbie who doesn't know what he's doing (i.e.
someone confused over self-signed certs)--then you end up risking sensitive data.

GlassFish Metro, for example, does not allow UsernameToken over HTTP, you have to use SSL
or message-level encryption along with it.  They do occasionally get unhappy devs on the Metro
User's list over it, but the Metro team doesn't care--they need to retain a minimum level
of security to protect sensitive data from errors that newbie developers might make.  

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-enhanced-warnings.patch, 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.


Mime
View raw message