I guess you can add additional info to the error message if you like, but the advantage of keeping as much of the regular text as possible is that it helps nicely with Googling. I'm reminded of something (I believe) Christian Scheider had said, that he does *not* like error messages to be translated into his native German because it's a pain trying to Google them to find out a solution to the error--he wants the standard vanilla English error text for Googling.
I'm happy we both like #2, even if it is a little bit more work to implement. If it becomes too problematic and we need to revisit #1, let us know. Glen cleclerc wrote: > > Hello, > > For the educational side, I feel we could help users enhancing the > exception messages. For example, a "SunCertPathBuilderException: > unable to find valid certification path to requested target" for a > self signed certificate could be more explanatory. > => I would be very happy to make propositions ont this like I did on > "CXF-2672: Enhance CXF client message in case of HttpRetryException > (http codes 401 and 407)". > > For option #2 which allows to use the JVM default SSLSocketFactory in > CXF client, I see two benefits : > 1. it is consistent with the usage of the JVM default Proxy Selector > that is used when no proxy is defined in the HTTP Conduit > 2. it allows infrastructure teams to disable ssl certificates > validation at the middleware level (I happily do it on Tomcat for both > http proxies and ssl certificates) > => I would be very happy to make propositions on this. > > Cyrille > > > On Thu, Mar 4, 2010 at 11:41 AM, Glen Mazza <glen.ma...@gmail.com> wrote: >> >> 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. >> > > -- View this message in context: http://old.nabble.com/-CXF-2688--%22Allow-deactivation-of-SSL-X509-Certificates-validation%22--reverted-tp27776275p27782227.html Sent from the cxf-dev mailing list archive at Nabble.com.
