Java and security bits

Friday Dec 02, 2005

JSSE now fully pluggable

J2SE 5.0 Update 6 was just released yesterday. One change I want to highlight is that the JSSE framework is now fully pluggable. This means you can use any 3rd party JSSE provider you wish. No restrictions on the ciphersuites that may be used. No code signing required from the developers that implement a JSSE provider.

So what does this mean for you? Ideally, nothing at all. I say that because I hope you are happy with the SunJSSE provider included in the Sun JDK and that you will just keep using it. But if you do not like SunJSSE, you can choose another provider. Or write your own, it's your choice. And choice is good.

So go ahead and download 5.0u6 or a Mustang build and play. Note the pluggability restrictions were also removed from Mustang a little while ago.

BTW, if you don't like SunJSSE, let us know why so we can fix it. Report a bug, contact the Java security feedback alias or email me directly and share your pain.

For those of you that care, let me explain a bit of the legal background. DISCLAIMER: I am not a lawyer. The following is not legal advice, only my limited understanding of the export control rules as they affect JSSE.

The U.S. government (and many other governments) is concerned that cryptography could be misused by criminals, so it imposes certain restriction on encryption software and hardware that is exported from the U.S. Although those constraints are far less severe than they used to be years ago and from a consumer perspective have all but disappeared, they still cause a bit of trouble for companies like Sun. Apart from lots of paperwork, one big issue that remains is open cryptographic interfaces. In other words, pluggable systems like JCE or JSSE. Unlimited pluggability is generally not approved.

That is why at one point we had two versions of JSSE: a domestic version that allowed 3rd party providers and an international one that did not. That was back when JSSE 1.0.x was an optional package for JDK 1.2 and 1.3. When JSSE became part of the core platform in JDK 1.4, maintaining two versions became impractical and we instead only shipped the non-pluggable international version.

Of course we wanted a better solution, and it finally arrived in JDK 5.0. We received approval from the government to allow 3rd party JSSE providers as long as they only supported the ciphersuites on a predefined list. That list includes all currently standardized ciphersuites, so it is a pretty good solution.

Still, the fact that there is any limitation at all was a little annoying. So we tried again and after a some back and forth we received approval to remove that restriction and allow any 3rd party JSSE provider without constraints. This probably does not sound like a bit achievement but it has been a long journey and I am glad it is over now.

Comments:

What about plugging new ciphers without signing required? Have you read anything?

Posted by taner on December 05, 2005 at 10:23 PM PST #

Do you mean allowing unsigned JCE providers that implement encryption algorithms? We currently don't have plans for that. We want to spend our limited resources where they will have the biggest impact on the community at large. The JCE code signing certs are easy to get and the process seems work fairly well, even though a little inconvenient for the limited number of developers that implement their own crypto providers. Of course, if there changes in the legal framework that would allow us to remove (some) of that complexity, we will react.

Posted by Andreas Sterbenz on December 07, 2005 at 03:04 PM PST #

Post a Comment:
Comments are closed for this entry.

Calendar

Feeds

Links

Recent Posts

Referers