Release Notes for ORBAsec SL3 3.5.0 =================================== This documentation describes anomalies with using ORBAsec SL3 with various products. For the configuration and anomalies with using J2SE, see the "INSTALL.txt" file for details. Changes Needed for Application Programs --------------------------------------- In the previous versions of ORBAsec SL3, application programs may use the following code to set system properties in initializing the ORBacus ORB: java.util.Properties props = System.getProperties(); props.put("ooc.orb.init_iiop","none"); This property disables the default IIOP transport provided by ORBacus ORB and use the secure transport provided by ORBAsec SL3. In ORBAsec SL3 3.4.1, you must change the above code into the following code: java.util.Properties props = System.getProperties(); props.put("ooc.oci.plugin.iiop","com.adiron.orbasec.sl3.IIOP"); This change is due to the change of OCI implementation between ORBacus 4.0.5 and ORBacus 4.1.0. Failing to change application programs will result in an org.omg.CORBA.INITIALIZE exception. Please see the "INTRO.txt" file for details. ORBacus 4.1.0 and ORBacus 4.1.1 ------------------------------- ORBacus 4.1.0 and 4.1.1 has known bugs in which memory leaks occur when Portable Interceptors are used. Also, GIOP Server Workers and Transports are never garbage-collected until a new client comes. We fixed these memory problems and provided a patched version of OB.jar in the "jars" directory. The patch for fixing these problems for the JOB 4.1.0 source code is provided by the files: JOB-4.1.0-patch-1 JOB-4.1.1-patch-1 To apply this patch, enter the JOB 4.1.0 or JOB 4.1.1. distribution directory and run the patch command: cd JOB-4.1.0 patch -p0 -i JOB-4.1.0-patch-1 or cd JOB-4.1.1 patch -p0 -i JOB-4.1.1-patch-1 Note that these patches are identical as the source code of JOB 4.1.0 and 4.1.1 is almost identical. Crypto Strength Limitation -------------------------- J2SE 1.4 includes a JCE framework implementation that has default jurisdiction policies that allow "strong" but limited cryptography due to import control restrictions of some countries. As a result, it has two impacts to ORBAsec SL3. Firstly, IAIK-iSaSiLk does the negotiation of crypto algorithms between a client and server based solely on the availability of crypto algorithm implementations, not considering about the jurisdiction policies at all. As a result, a chosen crypto algorithm may violate the limitation set in the policies and cause a SecurityException. In this case, you may get an exception that contains the following: java.io.IOException: Fatal SSL handshake error: java.lang.RuntimeException: Unable to create cipher AES/CBC/NoPadding: java.lang.SecurityException: Unsupported keysize or algorithm parameters Secondly, the CA program, a private key generation utility in ORBAsec SL3, cannot store generated private keys in PKCS12 format. This problem is because IAIK encrypts the private keys in PKCS12 files using 168 bits Triple DES with "PBEwithSHAAnd3_KeyTripleDES_CBC" as its algorithm identifier. Although the default jurisdiction policies allow Triple DES, but this Triple DES is not specified as PBEwithSHAAnd3_KeyTripleDES_CBC. Importing PKCS12 files to keystores using ORBAsec SL3's "CertUtil" program is not a problem because "CertUtil" uses the "SunJSSE" provider to read PKCS12 files. However, if you use J2SE's "keytool" to import PKCS12 files, you may encounter problems because the "DSTC_PKCS12" provider may be used as default. The "DSTC_PKCS12" provider may have higher priority over the "SunJSSE" provider because of the settings of the order of security providers suggested in the "INSTALL.txt" file. You may download an "unlimited strength" version of the jurisdiction policy files to avoid the above problems at the following web site: http://java.sun.com/j2se/1.4/download.html. Known Problems -------------- o On some old Linux systems such as Mandrake 6.0 (Kernel 2.2.9-19mdk), the generation of secure random numbers may take a long time and cause a long delay in SSL/TLS handshaking. Workaround: Use the insecure random number generater (java.util.Random) instead of the secure generator (java.security.SecureRandom). How to: Modify the sl3/src/common/com/adiron/orbasec/tlsiaik/ IAIK_SSLContext.java file and set the insecureRandom_ field to true. o The test for client-side automatic credentials release when object references are GC'ed may fail on a particular model of a Sun machine -- Blade 100, UltraSPARC-IIe, SunOS 5.8 Generic_108528-14. The same test succeeds on another Sun machine with slightly newer OS (Ultra 4, UltraSPARC-II, SunOS 5.8 Generic_108528-27). We have not fully investgated the cause of this problem. Product Testing --------------- ORBAsec SL3 has been tested on the following platforms Linux Mandrake 8.1 (Kernel 2.4.8) Solaris 2.8 Windows 2000 and XP and with the following products. Products | Versions -----------------------+---------------------- Sun Java 2 SDK SE | 1.3.1, 1.4.1, 1.4.2 IONA ORBacus for Java | 4.1.3 IAIK-JCE | 3.03 IAIK-iSaSiLk | 3.06 Wedgetail JCSI | 2.4.1, 2.5, 2.6 Jakarta Ant | 1.5.1 Please report any problems to "sl3-users@adiron.com" after subscribing to the list. Directions for subscribing are in the INTRO.txt file, and on our web site, http://www.adiron.com. Cheers, The Adiron ORBAsec SL3 Team. ------------------------------------------------------------------------ Copyright (C) 2004 Adiron, LLC. All rights reserved.