cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: In-memory Keystores, and Jetty
Date Fri, 23 Feb 2007 10:50:33 GMT

Fred,

Note that even in the client-side HttpsURLConnection-based code, AFAIK
the CXF code also wouldn't support using a pre-existing in-memory
representation of the keystore ... i.e. it expects to load the keystore
from a file. See SSLUtils.getKeyStoreManagers().

If you need the capability to pull in keystores from memory just for
testing, then I'd suggest it would be easier to just take a pragmatic
approach and dump into a temp file, rather than contributing a change to
Jetty. The reason I say this is that right now we depend on two separate
versions of Jetty, one current but the other quite old at this stage,
which would complicate the process of getting your change into released
snapshots on which we could depend. 

/Eoghan
 

> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net] 
> Sent: 22 February 2007 21:42
> To: cxf-dev@incubator.apache.org
> Subject: In-memory Keystores, and Jetty
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> - -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> I've been looking into Jetty, and in particular, its 
> initialization of TLS endpoint information via Java Keystores.
> 
> One thing I've found in the CXF use of Jetty is CXF populates 
> an org.mortbay.http.SslListener in
> org.apache.cxf.transport.https.JettySslListenerFactory#decorate():
> 
>      public void decorate(SslListener secureListener) {
>          String keyStoreLocation =
>              SSLUtils.getKeystore(sslPolicy.getKeystore(), LOG);
>          secureListener.setKeystore(keyStoreLocation);
>          ...
> 
> The idea being that later, the SslListener will load the 
> keystore off the URL:
> 
>      protected SSLServerSocketFactory createFactory()
>      	throws Exception
>      {
>          ...
>          KeyStore keyStore = KeyStore.getInstance(_keystoreType);
>          keyStore.load(Resource.newResource(_keystore).getInputStream
> (), _password.toString().toCharArray());
>          ...
>      }
> 
> However, this API on the Jetty SslListener type requires that 
> the Keystore be referenced indirectly through a string (it 
> seems that URLs are supported, though I don't see why you'd 
> want to get your keystore from an ftp server).  Not sure just 
> what the security implications are there...
> 
> In any event there doesn't seem to be a way of initializing 
> the connection with a Keystore that already in memory, which 
> is too bad, because an application may already have one in 
> memory, which it may have acquired by its own nefarious 
> methods.  As it is, the application will need to serialize 
> the thing to disk somehow.
> 
> It also makes testing a pain, in my particular case :)
> 
> Anyway, I don't see a way around this, other than by a fix to 
> Jetty.   
> Has this come up before?
> 
> Thanks,
> Fred
> 
> - -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
> 
> iD8DBQFF3g4CKSQw0yA4Kl8RAlogAJ4we6ZEXvFmZEVQ9hlk+NhvKUV+0QCdESi+
> 4HCKSLWTcBwwfDHnyDwHOvg=
> =RcrX
> - -----END PGP SIGNATURE-----
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
> 
> iD8DBQFF3g5FKSQw0yA4Kl8RAtYvAJ49Z1+TuqGo5p6sFUwG3m93bZ1wOACgiNlj
> FmQf5MBcbJI/gl/CSouubKI=
> =4M8k
> -----END PGP SIGNATURE-----
> 

Mime
View raw message