cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Stör <mar...@frightanic.com>
Subject Re: Using a custom SSLSocketFactory in HttpsURLConnectionFactory
Date Tue, 13 Apr 2010 21:20:59 GMT

On 13.04.2010, at 16:25, Daniel Kulp wrote:

> On Tuesday 13 April 2010 4:34:38 am Marcel Stör wrote:
>> In http://www.mail-archive.com/users@cxf.apache.org/msg13706.html I
>> asked how to configure CXF with a custom SSLSocketFactory. That issue
>> clearly belongs to the users list.
> 
> I think this has been answered now on the users list by allowing config to use 
> teh default SSLSocketFactory.   See the settings for 
> useHttpsURLConnectionDefaultSslSocketFactory at:
> 
> http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html

Yes, indeed. I was happy to learn that this option was added just recently (we were using
2.2.6 before).

>> The question why
>> HttpsURLConnectionFactory.decorateWithTLS(HttpURLConnection) does not
>> respect the (static) default SSLSocketFactory set through
>> javax.net.ssl.HttpsURLConnection.setDefaultSSLSocketFactory(SSLSocketFactor
>> y), however, can only be answered by you - the CXF committers.
>> 
>> I suppose there's a valid reason for that behavior?
> 
> Well, every customer I've talked to and every use case they've presented 
> pretty much says the "setDefaultSSLSocketFactory" method is not really usable 
> in a complex application where you need to talk to multiple endpoints that 
> have very different SSL requirements.   The CXF configs are setup to allow 
> each target endpoint to have very different settings and configuration and CXF 
> then uses that config to setup a properly configured SSLSocketFactory based on 
> those settings.

That's a very clever approach. Kudos to you committers for your foresight.

OT, just to add another potential use case...

In our case the pre-condition for the setup was a lot simpler. One of the customers of our
software is a Swiss bank (i.e. high security by definition). Their simple rule is that whenever
an application wants to talk to the out-side world, the web service host at our company in
this case, the request has to go through a very tight validating security proxy (extensive
input/output verification). Even the connection between the application host and the proxy
must use mutual authentication with server- and client-certificate although it's all within
the customer's own secured network infrastructure. Hence, even if the application needed to
talk to various endpoints the requests would have to go through the same proxy.
In our case, the only problem was that the customer uses his own configuration - and implementation
for certain things - for everything related to the actual SSL socket communication. Here the
requirements went even beyond the highly configurable CXF SSL support. It's common practice
within the customer's  IT department to make use of Java's default SSLSocketFactory feature.

Regards,
Marcel

-- 
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
Skype: marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


Mime
View raw message