I think there have been calls for option #2 for other reasons besides disabling the X509 checks. So #2 provides additional benefits--it's probably something we should be supporting anyway. I also like option #2 politically (we're not explicitly allowing disabling of the X509 checks, it's just we're allowing whatever they can do with Java) and the fact that it requires more effort than just setting a flag--it separates advanced users who know what they're doing (but truly and temporarily *do* need to disable the checks) vs. newbies who are greatly overestimating the difficulty of creating self-signed certs and adding the server cert to your local truststore (again[1] shows how this can be done in just a few minutes.) At any rate, you seem to be thinking that a newbie needing to learn the cert stuff would be a Bad Thing, but this skill, like learning Ant or Maven, is hardly useless knowledge for a Java developer, especially one planning on using SSL for web service calls.
Glen [1] http://www.jroller.com/gmazza/entry/setting_up_ssl_and_basic dkulp wrote: > > 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=cyri...@cyrilleleclerc.com, CN=localhost, OU=Cyrille Le >> Clerc, O=Cyrille Le Clerc, L=Paris, C=FR' > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > > -- View this message in context: http://old.nabble.com/-CXF-2688--%22Allow-deactivation-of-SSL-X509-Certificates-validation%22--reverted-tp27776275p27779137.html Sent from the cxf-dev mailing list archive at Nabble.com.
