Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates validation" reverted
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 >> 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 transport
Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates validation" reverted
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 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 > >> 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
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 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 >> >> 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 connecti
Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates validation" reverted
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 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 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 >>> >
[CXF-2693] "Allow to use HttpsURLConnection's defaultSSLSocketFactory and defaultHostnameVerifier in CXF client"
Dear all, After talks on the mailing list regarding ways to ease usage of HTTPS in CXF client I created "[CXF-2693] Allow to use HttpsURLConnection's defaultSSLSocketFactory and defaultHostnameVerifier in CXF client". If people are happy with this new feature, I would be very happy to commit the patch I attached to the jira issue. Cyrille https://issues.apache.org/jira/browse/CXF-2688
Re: [CXF-2688] "Allow deactivation of SSL X509 Certificates validation" reverted
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 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 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 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
