On Tuesday 04 March 2008, Benson Margulies wrote: > Dan, > > Browsers ship with a list of globally trusted CAs. Should we do that, > too?
We kind of already do. The JDK has a bunch of trusted CA's as well. That's the point. With my change, we allow the stuff already configured in the JDK to actually work when at all possible. Dan > > --benson > > On Tue, Mar 4, 2008 at 9:35 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > Donal, > > > > The use case that MUST work, IMO, is that if I am given an https URL > > to a service and that is it, that MUST work without having to go > > through a whole bunch of hoops and junk to get it configured. > > Every other toolkit on the planet will work. So should we. > > > > You don't go through a bunch of hoops and stuff to get your browser > > to talk HTTPS to amazon.com to buy things, do you? I didn't think > > so. This is the same thing. > > > > It may come down to a client vs server thing. For servers, sure, > > we should definitely make sure any services that are created meet > > minimal security requires. For client consuming services, however, > > we must make it work "out of the box" with as many of the services > > that are out there as possible. Give them the option to make sure > > it's more secure, but out of the box, it just works. > > > > Dan > > > > On Tuesday 04 March 2008, Arundel, Donal wrote: > > > Hi Dan, > > > > > > Cheers for the change to the default ciphersuite list :-) > > > > > > I have some comments relating to implications from your https > > > change though. > > > This regards the addition of support for automatically using https > > > instead of http when a URL starts with https. > > > > > > By itself this is a good idea, upgrading to SSL sounds fine in > > > isolation, > > > but.. > > > > > > 1) In general TLS requires some configuration for it to be worth > > > anything. > > > Minimally a trusted CA needs to be specified or you may as well > > > not be using SSL in practical terms.. You will speak to anybody! > > > (and be subject to man in the middle attacks to boot). Sure we can > > > default all the other stuff to be sensible (max cert chain length, > > > ciphersuites, protocol versions etc etc) but the trust config is > > > vital. > > > > > > 2) If the current use of CXF allows a user to NOT specify any > > > trusted CA by default and also interprets this as a desire to > > > accept any servers CA by default then this is an issue for two > > > reasons. > > > > > > a) It's a security issue as mentioned in 1). > > > Trusted CAs are such a vital config parameter that I think it > > > should be required by default. > > > Having the potential for things to work accidentally is something > > > that would normally be avoided in secure systems where possible. > > > i.e. one would default to the secure behaviour and force the user > > > to explicitly specify that they want the less secure behaviour. > > > > > > b) The newly added automatic detection for when to use secure > > > https comms based purely on the URL means that it would be very > > > easy to accidentally > > > introduce security to parts of your application that might make it > > > hard to audit later when you do want to make your application > > > meaningfully secure. i.e. specifically you could be using the > > > valueless "Accept any CA" mode by default. Things might look like > > > they are secure since "they work" but it's a false sense of > > > security. > > > > > > > > > 3) BTW Have you also (perhaps inadvertently) enabled the opposite > > > change? > > > i.e. Downgrading from https to http just because the URL starts > > > with http? I think this would be a security issue. > > > In most cases for secure applications a client should have an > > > advance expectation of whether a connection should be secure or > > > not. Since there are many dynamic ways of retrieving urls > > > (including over insecure HTTP or insecure wsdl publish) this would > > > effectively allow "dumbing down" of the client to insecure comms > > > when perhaps the author only wanted to use insecure comms to one > > > endpoint or most likely for a secure application perhaps none! :-) > > > > > > (Aside: There would be an advanced use case where a client might > > > be prepared > > > to use ether http or https depending on the servers requirements > > > but this is a less likely and less useful scenario - effectively > > > the client has no security requirements). > > > > > > I think three separate items might help here? > > > > > > a) If there was a way to easily specify the trust info or other > > > TLS parameters for all conduits or endpoints without repetition > > > then you would get the effect you are looking for (no SSL > > > per-conduit or endpoint config) > > > by simply specifying your root CA at a high enough logical scope > > > for it to be picked up by the connections. > > > Then any encountered HTTPS URL could be used without explicit > > > configuration but would result in meaningful authentication of the > > > server endpoints concerned. > > > > > > b) The CXF runtime disallowing null CA lists by default for non > > > anonymous ciphersuites. We could providing a config knob for folks > > > that really want this secure behaviour, this should be a small > > > majority of users. > > > > > > c) If your change has enabled the dumbing-down to http where https > > > was intended by the user the perhaps we should amend that > > > behaviour Again It might be possible to give more control over > > > this setting. Logically there are three scenarios: > > > i) client requires SSL > > > ii) client requires insecure comms > > > iii) client is happy to use either secure or insecure comms, > > > possibly with a preference specifier. > > > > > > Does this make (any/some/non) sense? :-) > > > > > > Cheers, > > > Donal > > > > > > -----Original Message----- > > > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > > > Sent: 03 March 2008 20:28 > > > To: cxf-user@incubator.apache.org > > > Cc: yulinxp > > > Subject: Re: Illegal Protocol https for HTTP URLConnection Factory > > > > > > > > > Yea. I hit this while testing your testcase as well. For some > > > oddball > > > > > > reason, using an address like "https" doesn't allow https to > > > actually be > > > > > > used. You MUST configure a TLSClientParameters thing on the > > > conduit prior to connecting. Kind of strange and I'm not exactly > > > sure why. Thus, you have to get the TLS thing configured either > > > via spring config or programatic config. > > > > > > In anycase, I fixed it this morning. :-) I'm going to deploy > > > new 2.0.5 and 2.1 snapshots later today. > > > > > > Dan > > > > > > On Monday 03 March 2008, yulinxp wrote: > > > > My excitement for my first CXF client connection didn't last > > > > long. Now I have another problem for my 2nd CXF client > > > > connection to > > > > https://mdf.ingenixmedpoint.com/mdfwebservices/hpretriever.asmx? > > > >WSDL > > > > > > > > > > > > The same exception happens even after I set httpconduit SSL. > > > > Why it would get a HTTP URLConnection Factory at the first > > > > place?? > > > > > > > > :confused: > > > > > > > > org.apache.cxf.interceptor.Fault: Could not send Message. > > > > at > > > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessag > > > >e(Me ss ageSenderInterceptor.java:48) at > > > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInte > > > >rcep to rChain.java:207) at > > > > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254) > > > > at > > > > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:205) > > > > at > > > > org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java: > > > >73) at > > > > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.ja > > > >va:1 35 ) at $Proxy27.getHealthProfileNDA(Unknown Source) > > > > at > > > > https.mdf_ingenixmedpoint_com.mdfwebservices.hpretriever.HPRetri > > > >ever WS > > > > Soap_HPRetrieverWSSoap_Client.main(HPRetrieverWSSoap_HPRetriever > > > >WSSo ap_ Client.java:57) Caused by: java.io.IOException: Illegal > > > > Protocol https for HTTP URLConnection Factory. > > > > at > > > > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.creat > > > >eCon ne ction(HttpURLConnectionFactoryImpl.java:44) at > > > > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.ja > > > >va:4 74 ) at > > > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessag > > > >e(Me ss ageSenderInterceptor.java:46) ... 7 more > > > > Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: > > > > Could not send Message. > > > > at > > > > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.ja > > > >va:1 75 ) at $Proxy27.getHealthProfileNDA(Unknown Source) > > > > at > > > > https.mdf_ingenixmedpoint_com.mdfwebservices.hpretriever.HPRetri > > > >ever WS > > > > Soap_HPRetrieverWSSoap_Client.main(HPRetrieverWSSoap_HPRetriever > > > >WSSo ap_ Client.java:57) Caused by: > > > > org.apache.cxf.interceptor.Fault: Could not send Message. at > > > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessag > > > >e(Me ss ageSenderInterceptor.java:48) at > > > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInte > > > >rcep to rChain.java:207) at > > > > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254) > > > > at > > > > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:205) > > > > at > > > > org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java: > > > >73) at > > > > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.ja > > > >va:1 35 ) ... 2 more > > > > Caused by: java.io.IOException: Illegal Protocol https for HTTP > > > > URLConnection Factory. > > > > at > > > > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.creat > > > >eCon ne ction(HttpURLConnectionFactoryImpl.java:44) at > > > > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.ja > > > >va:4 74 ) at > > > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessag > > > >e(Me ss ageSenderInterceptor.java:46) ... 7 more > > > > -- > > J. Daniel Kulp > > Principal Engineer, IONA > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
