Regarding exception messages, my mistake if my explanation was not clear enough. I share Christian's interest in root cause exception message in english to search google. My idea is to sometimes wrap root exceptions in exceptions that hold contextual messages ; I already proposed some enhancements in CXF-2537, CXF-2538 and CXF-2672.
I will propose an implementation of option #2 "allow to use JVM's default SSL Socket Factory in CXF client". I feel there is no overlap with option #1 even if it can be used for the same thing. In parallel, I feel it would be interesting to detail in CXF FAQ different techniques to handle self-signed and untrusted certificates. Another interesting feature could be "allow to inject the SSLSocketFactory in CXF client". To be transparent, I expect the most frequent usage would be to inject an 'EasySSLSocketFactory'. Cyrille https://issues.apache.org/jira/browse/CXF-2537 https://issues.apache.org/jira/browse/CXF-2538 https://issues.apache.org/jira/browse/CXF-2672 On Thu, Mar 4, 2010 at 4:26 PM, Glen Mazza <[email protected]> wrote: > > 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 <[email protected]> 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: >>> >> '[email protected], CN=localhost, OU=Cyrille Le >>> >> Clerc, O=Cyrille Le Clerc, L=Paris, C=FR' >>> > >>> > -- >>> > Daniel Kulp >>> > [email protected] >>> > 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. > >
