Java and security bits

Sunday Jul 16, 2006

Default SSLContext and SSLParameters

They say you cannot claim to have a blog unless you post something at least once a month. That means I am due ;-) So let me talk a bit about a couple of small API changes we made in JSSE: SSLContext.getDefault() and the new SSLParameters class.

The first set of changes relate to the default SSLContext. You are probably familiar with the getDefault() methods in SSLSocketFactory and SSLServerSocketFactory. These default factories are associated with a default SSLContext. Before JDK 6, there were a couple of problems with this SSLContext:

  • the only way to configure the key managers and trust managers of the default SSLContext (in the SunJSSE implementation) was via system properties. Although that may be convenient during development, putting passwords into insecure system properties is definitely not appropriate on production systems.

  • it was not possible to get an SSLContext object for the default context. That meant it was not usable with APIs that needed to access the SSLContext object. For example, creating an SSLEngine via the SSLContext.createSSLEngine() call.

The fix is pretty straightforward: we introduced the SSLContext.getDefault() and SSLContext.setDefault() methods. SSLSocketFactory.getDefault() and SSLServerSocketFactory.getDefault() were redefined to call SSLContext.getDefault(), unless the legacy security properties are set. SSLContext.getDefault() itself is specified to use the standard Provider architecture and call SSLContext.getInstance("Default").

SSLContext.setDefault() allows an application to programmatically set the default context to any initialized SSLContext object. That makes it possible to move away from using insecure system properties. For Dolphin, we are also considering introducing a framework that allows you to configure default private key and trust anchor stores on a per user and per application basis.

The second change I want to talk about is the new SSLParameters class. It encapsulates the configuration parameters of an SSL endpoint, in particular the ciphersuites, protocol versions, and for servers the client authentication requirements. They can be applied with a single call to SSLSocket.setSSLParameters() or SSLEngine.setSSLParameters().

The purpose of the class is to allow for more convenient configuration. It was introduced to support the embedded light-weight HTTP server API, but it is helpful in other situations as well.

Finally, on a more personal note, today is also the day of my fifth anniversary at Sun. Time sure flies! When I joined, we were just finishing up Merlin (JDK 1.4.0). My first real project was to change the SunJSSE code so that it could utilize JCE crypto providers. Before then, it only called its own internal crypto code using a proprietary API. As it happens, in Tiger I worked on that code again, this time to completely remove the JSSE internal crypto code and have it rely on JCE providers exclusively. And in Mustang, I touched it yet again. This time for the FIPS 140 compliance work, moving the session key generation code so that even that is now handled by JCE providers. We will see if I have to work on that code yet again in Dolphin. Regardless, I am definitely looking forward to my next five years here!

Comments:

What kills me about those static methods to get defaults in JSSE and JCE is that applications tend to use them without thinking that they are often not alone in the same JVM, so it is a really bad race.

Posted by Eugene Kuleshov on July 16, 2006 at 09:59 PM PDT #

Post a Comment:
Comments are closed for this entry.

Calendar

Feeds

Links

Recent Posts

Referers