Greetings,
As you know there as been some work done to correct/enhance the use of
SSL/TLS
in the Http modules. CXF-661, CXF-666, CXF-672.
In that effort, a significant change in the parameters for SSL/TLS was
required. It
added a new
setTLSServerParameters(TLSServerParameters params)
call in which the TLSServerParameters is more in-line with the JSSE,
which is
used exclusively for SSL/TLS transports. However, I kept the
setSSLServer(SSLServerPolicy policy)
call in order to maintain and not to break any existing configurations both
Spring and programmatic. Analogous stuff was done for the client side.
However, I have deprecated "setSSLServer()" and everything else
internally that is related
to it. That approach seems to be working. There seem to be some
complaints about the
"deprecation" compiler warnings.
The question is for version 2.0, since we are moving from 1.x, do we
want to eliminate the
old configuration all together? My feeling and some consensus relayed to
me is "yes".
I propose that we do remove the "setSslServer()" and "setSslClient()"
calls, and remove the
"SSLServerPolicy" and "SSLClientPolicy" elements from "security.xsd" .
This will force people to configure SSL/TLS using "TLSServerParameters" and
"TLSClientParameters" elements in "security.xsd" for spring
configuration and
"setTLSServerParameters()" and "setTLSClientParameters()" calls for
programmatic
configuration..
The next thing in the proposal to take care of the same time, is that
there is an issue about
conflicts in SSL/TLS configuration, which is hard, if not impossible, to
mitigate. This issue is that
there is a setTLSServerParameters() on the AbstractHTTPDestination and
also on
the JettyHTTPServerEngine.
The problem is that the JettyHTTPServerEngine can get its TLS
configuration from 2 places.
One being Spring configuration on bean name based on its implementation
"org.apache.cxf.http_jetty.JettyHTTPServerEngine.<port#>"
and the other indirectly by the configuration of the HTTPDestination,
because the destination
also holds a TLSServerParameters property.
This has consequences. The JettyHTTPServerEngineFactory creates
JettyHTTPServerEngine which
basically holds a configured java.net.ServerSocket or SSLServerSocket
depending
on whether the TLS configuration is present. The factory also caches
these so that different
HTTPDestinations can be published on the same socket (port number).
This leads to problems in the such as:
Endpoint.publish("https://localhost:9000/foo";, ...);
Endpoint.publish("https://localhost:9000/bar";,...);
when the second publish tries to "reconfigure" the retrieved already
configured JettyHTTPServerEngine
due to the HTTPDestination trying to submit its TLSServerParameters to
the already configured
JettyHTTPServerEngine.
The next item in the proposal is to remove SSL/TLS configuration (both
Spring and programmatic)
from the HTTPDestination all together, and only be able to configure the
SSL/TLS through the
JettyHTTPServerEngine. This is more in line with JSSE as HTTPS, is
merely HTTP over a JSSE
configured Socket.
Several things would need to be done to get this to work well.
Remove the methods
set/getSslServer()
set/getTLSServerParameters
from the AbstractHTTPDesination
and add:
JettyHTTPServerEngine getJettyHttpServerEngine();
to JettyHTTPDestination so that programmatic configuration may happen
like so:
EndpointImpl endpoint;
TLSServerParameters parms;
((JettyHTTPDestination)endpoint.getServer().getDestination()).
getJettyHTTPServerEngine().setTLSServerParameters(parms);
So, in summary of this entire proposal is the following:
1. Remove TLS configuration from the AbstractHTTPDestination.
2. Create an API to retrieve the JettyHTTPServerEngine from the
JettyHTTPDestination
3. Remove setSslServer() and setSslClient() from the APIs and remove
SSLServerPolicy
and SSLClientPolicy from the security.xsd.
4. Create a QName sutiable for Spring configuring the
JettyHTTPServerEngine without
using the internal fully qualified class name of its implementation.
I'll be working on this patch this afternoon. So please come up with any
discussion,
complaints, or suggestions (like for the QName Bean name for the
JettyHTTPServerEngine
spring configuration) ASAP.
Thanks,
-Polar
