Dan, Browsers ship with a list of globally trusted CAs. Should we do that, too?
--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: [email protected] > > 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 >
