How about a really specific exception to indicate that we're missing the CA config?
On Tue, Mar 4, 2008 at 7:04 AM, Arundel, Donal <[EMAIL PROTECTED]> 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(Mess > >ageSenderInterceptor.java:48) at > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto > >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:135 > >) at $Proxy27.getHealthProfileNDA(Unknown Source) > > at > > https.mdf_ingenixmedpoint_com.mdfwebservices.hpretriever.HPRetrieverWS > >Soap_HPRetrieverWSSoap_Client.main(HPRetrieverWSSoap_HPRetrieverWSSoap_ > >Client.java:57) Caused by: java.io.IOException: Illegal Protocol https > > for HTTP URLConnection Factory. > > at > > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createConne > >ction(HttpURLConnectionFactoryImpl.java:44) at > > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:474 > >) at > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(Mess > >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:175 > >) at $Proxy27.getHealthProfileNDA(Unknown Source) > > at > > https.mdf_ingenixmedpoint_com.mdfwebservices.hpretriever.HPRetrieverWS > >Soap_HPRetrieverWSSoap_Client.main(HPRetrieverWSSoap_HPRetrieverWSSoap_ > >Client.java:57) Caused by: org.apache.cxf.interceptor.Fault: Could not > > send Message. at > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(Mess > >ageSenderInterceptor.java:48) at > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto > >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:135 > >) ... 2 more > > Caused by: java.io.IOException: Illegal Protocol https for HTTP > > URLConnection Factory. > > at > > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createConne > >ction(HttpURLConnectionFactoryImpl.java:44) at > > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:474 > >) at > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(Mess > >ageSenderInterceptor.java:46) ... 7 more > > > > -- > J. Daniel Kulp > Principal Engineer, IONA > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland >
