I just saw your post about default CAs in the JDK.
Okay I agree that that would be fine out of the box :-)
My points below about client security policies still stand I think.
Cheers,
Donal
-----Original Message-----
From: Arundel, Donal [mailto:[EMAIL PROTECTED]
Sent: 04 March 2008 15:50
To: Daniel Kulp; cxf-user@incubator.apache.org
Subject: RE: Illegal Protocol https for HTTP URLConnection Factory
>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?
Actually you do in a way:
You will see this if you attempt to connect to a site that has a cert
signed by a private or little known CA :-)
Your browser will then immediately warn you that that you are connecting
to an untrusted site, Internet Explorer will for example give you a big
warning and prevent automatic navigation with the following options:
Cancel navigation
Inspect the certificate
Proceed (not recommended)
The reason why this isn't hitting you with a browser so much is that
every browser is shipped with pre-configured trusted CAs from the big
players. Essentially Microsoft or whoever is making a broad statement
of who it thinks you might want to trust to sign CAs in general
(the user can amend this list yourself).
This is fine and sensible in your role as a causal internet browser.
This is a million miles away from whether you want to securely transmit
sensitive data to a *specific* endpoint (or security domain) with some
assurance of security.
>Every other toolkit on the planet will work. So should we.
FWIW this has not been my experience of any SSL applications..
They need trusted CAs, otherwise they are just playing at using SSL.
I would imagine they all have some pre-canned CAs that perhaps you
aren't noticing, similar to browsers.
>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.
Hey, clients are people too :-)
Clients have every right to worry about whether the data they send is
secure or not.
What you are suggesting is that CXF defaults to the option C(iii) I
mentioned in my earlier post:
"i.e. client is happy to use either secure or insecure comms, possibly
with a preference specifier".
This effectively means that the client has no security assurance
whatsoever at runtime.
I'm not saying that we shouldn't make it easily possible to support this
specific scenario you want to support - my own opinion is that should be
a conscious decision following best security practice.
Ideally this would be supported by the ability to globally specify
policies like this.
Without the ability to easily specify these sort of policies at a high
level then I think that defaulting the client side of CXF to be exposed
to security risks is an appropriate default.
Cheers,
Donal
-----Original Message-----
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 04 March 2008 14:36
To: cxf-user@incubator.apache.org
Cc: Arundel, Donal
Subject: Re: Illegal Protocol https for HTTP URLConnection Factory
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
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
