geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kresten Krab Thorup <k...@trifork.com>
Subject Re: ActiveIO
Date Tue, 12 Jul 2005 08:14:07 GMT
Here are some notes on SSL configuration from IIOP/CSIv2 point of  
view.  This is not API, just what a such API need to do.  The Trifork  
ORB (note: Trifork is with just one capital letter) includes some  
code to do this, but it would make sense to integrate this into  
ActiveIO to make it more widely applicable.

For SSL we need a more elaborate configuration scheme.  These  
requirements are driven directly off the J2EE CSIv2 interop  
specifications.  In essence, we need to be able to specify these  
things on a per-bean level; which is probably best to do by a level  
of indirection, by having "named server socket configuration"s that  
can be referenced symbolically from the container-specific deployment  
descriptors.

For an SSL ServerSocket we need

     protocols=(SSL),(TLS)
     ciphers=<ALGORITHM,...>
     hashes=<ALGORITHM,...>
     keyexchanges=<ALGORITHM,...>
     requireTrustClient=REQUIRE|SUPPORT|NONE
     requireTrustServer=REQUIRE|SUPPORT|NONE

For both cipers, hashes and keyexchangees, the list can include the  
NULL algorithm.

These properties are used to select which cipher suites should be  
enabled for a given socket (the idea is to simply subset the  
"available cipher suites" on the active SSL provider).  Cipher suites  
are named like this:

     (TLS|SSL)_<KEYEXCHANGE>_WITH_<CIPHER>_<HASH>

If there is a key exchange mechanism (other than anonymous Diffie- 
Hellman "DH_anon"), then the SSL context also needs access to a key  
store with a key corresponding to the key exchange mechanism, and  
also a trust store used to validate the other parties.  These two are  
represented by

     javax.net.ssl.X509TrustManager
     javax.net.ssl.X509KeyManager

Both of these essentially represent a "keystore that has been opened  
(password unlocked)" as well as some policies for trust and key  
validation.  It would make sense to simply expose instances of these  
as GBeans directly in the geronimo infrastructure, and then name  
these objects so they can be referenced from the SSL configuration.

The require-trust parameters determines if client/server side trust  
is required or just supported.  In the former case, client hand-shake  
should be completed successfully before the socket is passed back.   
If either of these is REQUIRE then only cipher suites with a non-null  
key exchange mechanism can be allowed.

For client sockets, things are slightly more complicated because we  
need to support that the user is authenticated with an X509  
certificate.  In this case, the credentials of the user (which would  
typically be sitting inside the current Subject) needs to be passed  
along to the socket creation so that the SSL logic can create an  
X509KeyManager that can service this information to the server if he  
needs it to establish the clients credentials.



Kresten Krab Thorup
krab@trifork.com

"We do not inherit the Earth from our parents, we borrow it from our  
children." Saint Exupery


Mime
View raw message