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: > '[email protected], CN=localhost, OU=Cyrille Le > Clerc, O=Cyrille Le Clerc, L=Paris, C=FR' -- Daniel Kulp [email protected] http://dankulp.com/blog
