[security-dev 00507]: Re: SSLContextFactory

[Bruno Harbulot]

Hi Xuelei,

Thanks for looking into this.
I agree with you, everything that's required is already in the JavaSE 
API. I find, however, that using these classes requires a careful 
reading of the JSSE ref. guide and the Certification path ref. guide, 
both of which are rather long and non-trivial (at least to me). I 
suspect many developers don't have time to get into such a depth of details.

One of the use-cases that was the motivation for PKIXSSLContextFactory 
in jSSLutils was to be able to add CRLs quite easily. Thus, you get 
something like this:

PKIXSSLContextFactory sslContextFactory =
     new PKIXSSLContextFactory(keyStore, "keypassword", trustStore);
sslContextFactory.addCrl("http://ca.example.org/root-crl");
sslContextFactory.addCrl("http://ca.example.org/intermediate-crl");
SSLContext sslContext = sslContextFactory.buildSSLContext();

It's true that it's not possible to cover all cases, but I would guess 
that there is small set of cases that are more frequent (such as adding 
CRLs explicitly).
Even some high-profile projects don't necessarily handle this case, or 
haven't been doing it for a long time (for example, as far as I can see, 
CRL support was added to Tomcat only in 2006, and it accepts only one 
CRL file).

I was only suggesting that an SSLContext factory be added to the main 
API because it seems that a few projects create their own (named one way 
or another). Having an SSLContextFactory interface and perhaps a default 
PKIX-based implementation (or following the default value) that would 
take a keystore and truststore (or fall back to either default values) 
might help harmonise the practice amongst various projects (such as 
Tomcat, Grizzly/Glassfish, Jetty, Restlet, ...).

This being said, perhaps the main Java API isn't the right place for 
this. It can be in a separate library indeed.

Best wishes,

Bruno.


Xuelei Fan wrote:
> Hi Bruno,
> 
> I have read your jsslutils project times, it is a really good practice 
> to wrap complex logics into a simple one.
> 
> By my understanding (If I'm wrong or something missed, correct me), the 
> underlying requirements for SSLContextFactory are:
> 1. multiple SSLContext instances per thread or request.
> 2. customizable key/trust managers.
> 3. support CRLs.
> 
> Let's discuss it one by one:
> 1. multiple SSLContext instances per thread or request.
>    SSLContext.init(KeyManager[], TrustManager[], SecureRandom)[1][2] 
> could be used to create SSLContext at anytime you want to.
> 
> 2. customizable key/trust managers.
>    KeyManagerFactory[3] defines two initialization methods, 
> KeyManagerFactory.init(KeyStore, char[]) and 
> KeyManagerFactory.init(ManagerFactoryParameters). Both of the methods 
> could be used to customized the key managers.
>    Similarly, TrustManagerFactory[4] also defines two initialization 
> methods, TrustManagerFactory.init(KeyStore, char[]) and 
> TrustManagerFactory.init(ManagerFactoryParameters). Both of the methods 
> could be used to customized the trust managers.
> 
>    Once the customized key/trust managers created, you can use the above 
> SSLContext.init() method for a customized SSLContext.
> 
> 3. support CRLs.
>    It is flexible to support CRLs for trust managers with 
> TrustManagerFactory.init(ManagerFactoryParameters), please refer to 
> [5]-[10] step by step.
> 
> OK, by now, the current interfaces meets your requirements, I think. So, 
> I'm not really want to add a new SSLContextFactory.
> 
> And Cert path build and validation is a very very complex process for 
> enterprise environments, which concerns policies, constraint, date, 
> cross trust, etc. I don't think there is a simple way to hide the 
> complex in a general API. For the SSLContextFactory, in order to 
> provider enough candidate for various policies, constraints, a dozen of 
> sub-class must be defined, I don't think it is good.
> 
> So, because the TrustManagerFactory/KeyManagerFactory has provide the 
> flexibility, I don't think we still need a SSLContextFactory any more.
> 
> Thanks,
> Xuelei
> 
> [1]: http://java.sun.com/javase/6/docs/api/javax/net/ssl/SSLContext.html
> [2]: 
> http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLContext 
> 
> [3]: 
> http://java.sun.com/javase/6/docs/api/javax/net/ssl/KeyManagerFactory.html
> [4]: 
> http://java.sun.com/javase/6/docs/api/javax/net/ssl/KeyManagerFactory.html
> [5]: 
> http://java.sun.com/javase/6/docs/api/javax/net/ssl/ManagerFactoryParameters.html 
> 
> [6]: 
> http://java.sun.com/javase/6/docs/api/javax/net/ssl/CertPathTrustManagerParameters.html 
> 
> [7]: 
> http://java.sun.com/javase/6/docs/api/java/security/cert/CertPathParameters.html 
> 
> [8]: 
> http://java.sun.com/javase/6/docs/api/java/security/cert/PKIXBuilderParameters.html 
> 
> [9]: 
> http://java.sun.com/javase/6/docs/api/java/security/cert/PKIXParameters.html 
> 
> [10]: 
> http://java.sun.com/javase/6/docs/api/java/security/cert/PKIXParameters.html#setCertStores(java.util.List) 
> 
> [11]: 
> http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#StorageClasses 
> 
> 
> Bruno Harbulot wrote:
>> Hello,
>>
>> I only found out recently about Sean Mullan's blog entry named 
>> "Security Feature Planning for JDK 7" (written almost two years ago) 
>> <http://weblogs.java.net/blog/mullan/archive/2006/08/security_featur.html>. 
>> After I contacted him, he kindly suggested this mailing-list could be 
>> the right place to discuss security features in JDK 7.
>>
>> I've recently been trying to improve SSL support in a couple of 
>> open-source projects. This led me to build a small library, which I've 
>> called 'jsslutils' <http://code.google.com/p/jsslutils/>.
>> The idea behind this library is to provide an SSLContextFactory which 
>> can help configure an SSLContext for applications such as Restlet 
>> <http://www.restlet.org/> (Grizzly, Simple or Jetty connectors) or 
>> Jetty <http://www.mortbay.org/jetty/>. Sub-classes of 
>> SSLContextFactory can provide extra features such as helping with the 
>> configuration of CRLs, or customization of the Key/TrustManagers. (If 
>> you wish to try it out, there are some jUnit tests in the subversion 
>> repository.)
>> I would be interested in having your opinions regarding an 
>> SSLContextFactory, and whether something similar may have already been 
>> discussed. Looking at the JDK 7 API, there doesn't seem to be an such 
>> a class/interface. This has been a rather useful feature for my 
>> application so far, and it should make it easy to support CRLs for 
>> example in something like Jetty. However, I'm not sure whether it 
>> would be good to have something like this SSLContextFactory in JDK 7. 
>> Perhaps there are other better ways to achieve these goals.
>>
>> One of the main problems I still find is that few applications support 
>> setting up the SSLContext, which makes it sometimes difficult to 
>> configure more advanced features such as CRLs. Java 6 provides a way 
>> to set a default SSLContext, but this is not ideal. Sometimes, various 
>> connectors in the application may want to use different SSLContexts 
>> (perhaps with different truststores and keystores). For example, I 
>> would like to be able to set a specific SSLContext when using 
>> JavaMail, but I haven't found any documentation making it possible to 
>> set up the truststore and keystores independently, instead, it seems 
>> to rely on the default system properties.
>>
>>
>> Best wishes,
>>
>> Bruno.
>