I started a new thread on the mailing list to propose an implementation of option #2 : "[CXF-2693] Allow to use HttpsURLConnection's defaultSSLSocketFactory and defaultHostnameVerifier in CXF client"
Could you give me a feedback on this implementation ? Is it the kind of thing you thought about or are there misunderstandings ? Cyrille On Thu, Mar 4, 2010 at 4:58 PM, Cyrille Le Clerc <[email protected]> wrote: > 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. >> >> >
