Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of polar.humenn@iona.com
 designates 65.223.216.181 as permitted sender)
Message-ID: <464DC398.8000505@iona.com>
Date: Fri, 18 May 2007 11:17:44 -0400
From: Polar Humenn <phumenn@iona.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070403)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: HttpConduitTest failed when Jetty upgraded to 6.1.3
References: <464A84F3.2050509@iona.com> <464B016C.9000307@iona.com>
 <464BBC15.4060009@iona.com> <464DB7EC.3020401@iona.com>
 <9A4696F35B459043970EE4A85A3173900254EE@amer-ems1.IONAGLOBAL.COM>
In-Reply-To: <9A4696F35B459043970EE4A85A3173900254EE@amer-ems1.IONAGLOBAL.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jiang, Ning (Willem) wrote:
> Hi Polar,
>
> It is greate that you security expert can do this upgrade.
>
> I just touched some Jetty SslSocketConnector code. Here are my comments about the JIRA CXF-661.
>   
This Jira is just about making the underlying socket get "decorated" 
with the SSLServerPolicy when setSSLServer() is called on the 
JettySSLDestination. Currently you can do that, but nothing happens, 
because "retrieveEngine" needs to be called. However, that method is not 
public.

I propose and have a patch to mimic the stuff I did with config to the 
HTTPConduit, basically after the Destination is configured, the 
setSSLServer will automatically call retrieveEngine.

The other stuff below is a different issue, but somewhat related.
> The old way of CXF do in the SslSocketConnector is we just wrapper the SslSocketConnector and do litter decoration work. 
> If you want to do some programatical configuration on the SSL socket, I think we can extends Jetty's SslSocketConnector.
>
>   

Since Jetty only allows file named based keystores I propose do exactly 
that. Just entend the Jetty SSL connector and use keystore/keymanager 
objects to configure it. It's not hard and should work as well things 
currently work.

The hard part is figuring out what the Spring Configuration is going to 
look like.

Cheers,
-Polar
> BTW
> Jetty's NIO ssl connector still need to be solid, I am not sure if it can support the complicated security usecase now. 
>
> Jetty uses SocketConnector for classical Java network listerning, and it supports the block and noblock NIO with BlockingChannelConnector and SelectChannelConnector.
>
> We may do some refactoring work to let CXF support these different connector more easyly.
>
>
> Cheers,
>
> Willem.
>
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: Fri 5/18/2007 22:27
> To: cxf-dev@incubator.apache.org
> Subject: Re: HttpConduitTest failed when Jetty upgraded to 6.1.3
>  
> Willem,
>
> I can take care of upgrading to Jetty 6.1.3. But I want to do a couple 
> of things along the way.
>
> I want to fix the SSL Configuration, (is anybody adverse to this?) and I 
> also want to be able to programatically configure destination, which is 
> presently impossible for Jetty SSL Destination (I filed JIRA CXF-661).
>
> Fred and I also want to be able to configure these with Keystore or 
> KeyManager objects without having to indirectly specify it through file 
> name, as currently it must be done. For Spring config keystore or 
> keymanagers may be supplied with beans.
>
> There is also a point I'd like to do. Jetty has been factored out to 
> separate it from the client side, but the server stuff is still 
> dependent on the client libraries. I'd like to be able to separate them 
> and make them independent.
>
> Does anybody have objections to this?
>
> Cheers,
> -Polar
>
> Willem Jiang wrote:
>   
>> Hi Polar,
>>
>> Please see my comments in the mail.
>>
>> Polar Humenn wrote:
>>     
>>> Aside from the incompatibilities with a new version of Jetty, CXF SSL 
>>> configuration has a lot of shortcomings. I've been burned by the same 
>>> thing.
>>>
>>> First of all, as Eoghan might say, I tore my hair out, before I found 
>>> out that if your authentication certificate/key is in a PKCS12 
>>> format, then your TrustStore has to be a PEM certificate, not a 
>>> truststore, i.e. PCKS12 or Java Key Store (JKS) format. This must 
>>> have made sense to someone about not mixing PCKS12 with JKS or 
>>> others, but makes no logical sense to me. So, Willem, if the 
>>> truststore is *just* a certificate, then there is no password 
>>> possible. Furthermore, when you use this approach you are only 
>>> allowed to have *1* certificate in the truststore.
>>>
>>>       
>> I don't mean not to set the TrustStroePassword to be null.
>> Current Jetty SslSocketConnector don't support to set the 
>> TrustStroePassword to be null.
>> Now I don't find a way to walk around it. It just may take some time 
>> to convince Jetty guys to change the code.
>>     
>>> So, the basic upshot is that if you initialize a PCKS12 
>>> key/certificate, then you are only allowed to have only 1 trust 
>>> point.  Most browsers have something like 100.
>>>
>>>       
>> We can support the TrustStroePassword with null value in CXF , right.
>>     
>>> So, this approach is really unacceptable. I would like to revamp SSL 
>>> configuration and the whole approach to include:
>>>
>>> 1. Different types Keystores for the the authentication private 
>>> keys/certificates/chains.
>>> 2. Different types of password protected TrustStores with multiple 
>>> trust points.
>>>     2a. I don't really care about passwords on TrustStores, as they 
>>> are mainly for
>>>           for integrity protection (somebody doesn't slip on in 
>>> there), but the user
>>>           should have the option of forgoing that, say, just a 
>>> concatenated list of
>>>           of PEM certificates.
>>> 3. Remove the restrictions between the keystore type and the 
>>> truststore type.
>>>
>>> Thinking quickly, this will add two elements to the SSL Policy 
>>> configuration for both Client and Server sides.
>>>
>>> <TrustStoreType>
>>> <TrustStorePassword>
>>>
>>>       
>> Let's add the TrueStorePassword to the SSL Policy configuration. :)
>>     
>>> Cheers,
>>> -Polar
>>>
>>> Willem Jiang wrote:
>>>       
>>>> Hi
>>>>
>>>> I found the HttpConduitTest failed in Systest when I upgraded the 
>>>> Jetty version from 6.1.2rc0 to 6.1.3.
>>>> I checked the Jetty's SslSocketConnector change log, and found that 
>>>> the errors are related with the different trustManager
>>>> setting on the Server and Client side. In another words,CXF now does 
>>>> not support to load the cert with password.
>>>>
>>>> Current CXF JettySslConnectorFactory doesn't do any trustManager 
>>>> setting, and the jetty will set the trustManagers to null,
>>>> if there is no setting for the _truststore.
>>>> But after Jetty 6.1.2rc5, the TrustManager will be initiated whether 
>>>> you do the trustManager setting or not.
>>>>
>>>> [*Server side*]
>>>>
>>>> Here is the Jetty SslSocketConnector TrustManagers Code, the 
>>>> trustStore load the  with a _trustPassword which can't be null.
>>>>
>>>>         
>>>>>>> after 6.1.2rc5
>>>>>>>               
>>>>        if (_truststore==null)
>>>>        {
>>>>            _truststore=_keystore;
>>>>            _truststoreType=_keystoreType;
>>>>        }
>>>>         
>>>>       ......
>>>>       TrustManager[] trustManagers = null;
>>>>       if (_truststore != null)
>>>>        {
>>>>            KeyStore trustStore = KeyStore.getInstance(_truststoreType);
>>>>            
>>>> trustStore.load(Resource.newResource(_truststore).getInputStream(), 
>>>> _trustPassword.toString().toCharArray());
>>>>                      TrustManagerFactory trustManagerFactory = 
>>>> TrustManagerFactory.getInstance(_sslTrustManagerFactoryAlgorithm);
>>>>            trustManagerFactory.init(trustStore);
>>>>            trustManagers = trustManagerFactory.getTrustManagers();
>>>>        }
>>>>
>>>> [*Client side*]
>>>> CXF SSLUtil is responsible for the creation of  the TrustManager,  
>>>> but it just load the cert with null password.
>>>> protected static TrustManager[] getTrustStoreManagers( ...
>>>>           KeyStore trustedCertStore = 
>>>> KeyStore.getInstance(trustStoreType);
>>>>  ......               trustedCertStore.load(new 
>>>> FileInputStream(trustStoreLocation), null);
>>>>  ......
>>>> I went through The SSLClientPolicy and SSLServerPolicy , there is no 
>>>> attribute for the TrustStorePassword.
>>>>
>>>> I also check the KeyStore.loadload(InputStream stream, char[] 
>>>> password) API
>>>> *the password used to check the integrity of  the keystore, the 
>>>> password used to unlock the keystore,  or <code>null</code> *
>>>>
>>>> This issue can be solved from two side.
>>>> One is let Jetty SslSocketConnector support calling the 
>>>> trustStore.load with the password to be null.
>>>> The other is we still need CXF SSL{Client|Server}Policy support 
>>>> TrustStorePassword attribute.
>>>>
>>>> IMO, we need to add the TrustStorePassword attribute to the 
>>>> SSL{Client|Server}Policy.
>>>>
>>>> Any thoughts?
>>>>
>>>> Cheers,
>>>> Willem.
>>>>
>>>>         
>>>
>>>       
>> Cheers,
>> Willem.
>>
>>     
>
>
>
>