cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates validation" reverted
Date Thu, 04 Mar 2010 03:16:43 GMT

I personally prefer option #1 as well.   As you noted, the code was already 
there, just commented out.  That's because I've needed this several times 
before when debugging issues that people have sent me.   Having a config 
option is much better as I wouldn't need to run the test cases in a modified 
environment.


That said, supporting the same SSL_SOCKET_FACTORY key on the request context 
that the JAX-WS RI has is definitely an intrigueing idea.   Wouldn't be hard 
to do either.  

Dan


On Wednesday 03 March 2010 9:07:21 pm Cyrille Le Clerc wrote:
>    Dear all,
> 
>    I am deeply sorry for my premature commit on [CXF-2688] "Allow
> deactivation of SSL X509 Certificates validation". I reverted
> everything and I would be happy to discuss the point on the mailing
> list.
> 
>    The idea of CXF-2688 was to ease usage of self-signed certificates
> on non-production environments. It would be similar to the
> "disableCNCheck" feature we have since 2.0.5.
> 
> 
>    I looked at the other SOAP/REST clients (axis2, jaxws-ri,
> spring-ws&rest, jersey and resteasy) : they offer the ability to
> deactivate ssl certificates validation and hostname verification
> either via Jakarta Commons Http Client or via the system-wide security
> settings of HttpsUrlConnection (see references below).
> 
> 
>    I would like to propose several scenarios to ease usage of such
> untrusted or self-signed certificates :
> 
> 1) Ability to deactivate certificates validation via HTTP Conduit
> configuration
> 
>    To rely on Spring's PropertyPlaceholderConfigurer that is often
> used to adjust configurations between environments and very well
> integrated in CXF with parameterized types, I declared a
> parameterized-boolean property "trustAllCertificates" on the
> <http-conf:tlsClientParameters /> element. To take the security point
> raised by Glen in account, I added emission of detailed severe log
> messages each time an HTTP Conduit is initialized with the
> "trustAllCertificates" feature and each time an HTTPS connection is
> established against an untrusted or a self-signed certificate.
> 
> pros : easy to use
> cons : potential security risk if someone enables by mistake this
> feature on production environment. This risk is mitigated by detailed
> error messages when the feature is enabled (see sample below or on
> CXF-2688).
> 
> 2) Ability to use the JVM default SSL Socket Factory
> 
>    The idea is pretty similar to the "trustAllCertificates", we could
> add a parameterized-boolean attribute "useDefaultSSLSocketFactory" and
> then rely on javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory().
> then the user would have the responsibility of declaring create his
> AcceptAllSSLSocketFactory
> 
> pros : the responsibility of deactivating key security features would
> not be located in CXF but in a system-wide property
> cons : similar idea to the "trustAllCertificates" attribute but more
> complex for the users
> 
> 3) Do not allow to deactivate certificates validation but enhance
> documentation
> 
>    We could improve the docs on the web site and print the URL of the
> doc in case of exceptions related to untrusted certificates
> exceptions.
> 
> pros : no security risk at all
> cons : usage of self signed or untrusted certificates on
> non-production will still be complex for many people.
> 
> 
>    I prefer the first scenario but I would be very happy to help on
> any initiative that would help usage of HTTPS.
> 
>    Cyrille
> 
> 
> https://issues.apache.org/jira/browse/CXF-2688
> 
> References :
> 
> Jersey - Security with Http(s)URLConnection :
> https://jersey.dev.java.net/nonav/documentation/latest/user-guide.html#d4e7
> 53 JAXWS-RI - HTTPS SSLSocketFactory :
> https://jax-ws.dev.java.net/guide/HTTPS_SSLSocketFactory.html
> Spring WS - Client HTTP transports :
> http://static.springsource.org/spring-ws/sites/1.5/reference/html/client.ht
> ml Spring REST - RestTemplate ClientHttpRequestFactory :
> http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference
> /html/remoting.html#rest-client-access Axis2 - Transports -
> CommonsHTTPTransportSender :
> http://ws.apache.org/axis2/1_5/http-transport.html#CommonsHTTPTransportSend
> er JBoss RestEasy - Client Framework & Commons Http Client:
> http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/1.2
> .GA/userguide/html/RESTEasy_Client_Framework.html Commons Http Client,
> EasySSLProtocolSocketFactory, self-signed and untrusted SSL certificates :
> http://hc.apache.org/httpclient-3.x/sslguide.html
> 
> 
> Sample of log messages
> 
> log message at HTTP Conduit initialization :
> 
> 2010/03/04 00:33:26,239 ERROR [http-8080-2]
> org.apache.cxf.transport.https.HttpsURLConnectionFactory - X509
> CERTIFICATE VALIDATION
>  SHOULD NOT BE DEACTIVATED ON PRODUCTION WITH
> "<http-conf:tlsClientParameters trustAllCertificates='true' />" !
>  SECURITY IS COMPRIMISED !
> 
> log message each time an HTTPS connection is opened against an
> untrusted certificate
> 
> 2010/03/04 00:33:27,179 ERROR [http-8080-2]
> org.apache.cxf.transport.https.AcceptAllCertificatesX509TrustManager -
> DEACTIVATED
>  X509 CERTIFICATE VALIDATION ERROR ! SECURITY IS COMPROMISED !
> CERTIFICATE VALIDATION DEACTIVATION
>  SHOULD NOT BE USED IN PRODUCTION !
> sun.security.validator.ValidatorException: PKIX path building failed:
>  sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target
> 2010/03/04 00:33:27,180 ERROR [http-8080-2]
> org.apache.cxf.transport.https.AcceptAllCertificatesX509TrustManager -
> Untrusted self-signed certificate:
>  'EMAILADDRESS=cyrille@cyrilleleclerc.com, CN=localhost, OU=Cyrille Le
> Clerc, O=Cyrille Le Clerc, L=Paris, C=FR'

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message