You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2010/03/04 16:26:25 UTC
Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates
validation" reverted
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 <gl...@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.
Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates
validation" reverted
Posted by Cyrille Le Clerc <cl...@apache.org>.
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
<cy...@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 <gl...@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 <gl...@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.
>>
>>
>
Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates
validation" reverted
Posted by Cyrille Le Clerc <cy...@cyrilleleclerc.com>.
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 <gl...@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 <gl...@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.
>
>