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
