cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyrille Le Clerc <clecl...@apache.org>
Subject Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates validation" reverted
Date Fri, 05 Mar 2010 00:29:13 GMT
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
<cyrille@cyrilleleclerc.com> 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 <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