cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyrille Le Clerc <cyri...@cyrilleleclerc.com>
Subject Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates validation" reverted
Date Thu, 04 Mar 2010 15:58:47 GMT
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 <glen.mazza@gmail.com> 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 <glen.mazza@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=cyrille@cyrilleleclerc.com, CN=localhost, OU=Cyrille
Le
>>> >> Clerc, O=Cyrille Le Clerc, L=Paris, C=FR'
>>> >
>>> > --
>>> > Daniel Kulp
>>> > dkulp@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.
>
>

Mime
View raw message