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.handleMessage(Me > >ss ageSenderInterceptor.java:48) at > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercep > >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.java:1 > >35 ) at $Proxy27.getHealthProfileNDA(Unknown Source) > > at > > https.mdf_ingenixmedpoint_com.mdfwebservices.hpretriever.HPRetriever > >WS > > Soap_HPRetrieverWSSoap_Client.main(HPRetrieverWSSoap_HPRetrieverWSSo > >ap_ Client.java:57) Caused by: java.io.IOException: Illegal Protocol > > https for HTTP URLConnection Factory. > > at > > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createCon > >ne ction(HttpURLConnectionFactoryImpl.java:44) at > > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:4 > >74 ) at > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(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.java:1 > >75 ) at $Proxy27.getHealthProfileNDA(Unknown Source) > > at > > https.mdf_ingenixmedpoint_com.mdfwebservices.hpretriever.HPRetriever > >WS > > Soap_HPRetrieverWSSoap_Client.main(HPRetrieverWSSoap_HPRetrieverWSSo > >ap_ Client.java:57) Caused by: org.apache.cxf.interceptor.Fault: > > Could not send Message. at > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(Me > >ss ageSenderInterceptor.java:48) at > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercep > >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.java:1 > >35 ) ... 2 more > > Caused by: java.io.IOException: Illegal Protocol https for HTTP > > URLConnection Factory. > > at > > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createCon > >ne ction(HttpURLConnectionFactoryImpl.java:44) at > > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:4 > >74 ) at > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(Me > >ss ageSenderInterceptor.java:46) ... 7 more -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
