HCL Users, HCL 1.5.7 has been released. It fixes a very small list of bugs that were found since HCL 1.5.6 was released, and contains no new features or public API changes. The list of bugs fixed in HCL 1.5.7 is below. The release notes for HCL 1.5.6 are appended to these notes. ALL SERVERS should abandon HCL 1.5.6 and switch to HCL 1.5.7 ASAP. The reasons for this strong recommendation should be self apparent after reading the list of bugs fixed. We recommend that all sources that include HCL headers be recompiled with the new HCL 1.5.7 headers. This is only a precaution. Security Library 1.57 Build Date: 19980902 **************************************************************** ** ** NOTE: THIS RELEASE IS NOT BINARY COMPATIBLE WITH 1.55 ** AND ANY APPLICATION CODE WILL HAVE TO BE RECOMPILED ** **************************************************************** **************************************************************** ** ** Directory organization of this release ** **************************************************************** This release consists of the following: - a JAR file, xpheader.jar, that contains all of the public header files. - directories: where is of the form [_][_]_.OBJ For example, IRIX6.2_DBG.OBJ (debug build) SunOS5.5.1_OPT.OBJ (optimized build) SunOS5.5.1_gcc_DBG.OBJ (built using the non-native compiler gcc) OSF1V4.0_PTH_DBG.OBJ (PTH means the implementation uses pthreads.) AIX4.1_PTH_USER_DBG.OBJ (PTH_USER means the implementation is a combination of user-level threads and pthreads.) Under each directory, is the file, mdbinary.jar. This is a JAR file containing the compiled libraries. ************************************************************ ** ** Platforms supported ** ************************************************************ The following platforms are supported: - Solaris on sparc: 2.5.1, 2.6 (built with cc) - IRIX: 6.2, 6.3 (built with cc) - HP-UX: B.10.10, B10.20, B11.00 (built with cc) - OSF1: V4.0D (built with cc) - AIX: 4.2 (built with compiler xlC_r). - Linux: 2.1.108 - WINNT: 4.0 (Visual C++ 4.2 built with and without debug runtime) ************************************************************ ** ** How to build the libraries yourself ** ************************************************************ This release of HCL depends on NSPR version 19980529A and DBM version DBM_1_53. To build the libraries yourself, execute the following instructions. On UNIX machines: cvs co -r HCL_157 ns/security cvs co -r HCL_157 ns/coreconf cd ns/coreconf source ./.cshrc gmake [BUILD_OPT=1] cd .. cd security gmake [BUILD_OPT=1] import gmake [BUILD_OPT=1] On Windows NT machines: cvs co -r HCL_157 ns/security cvs co -r HCL_157 ns/coreconf cd ns/security gmake [BUILD_OPT=1] import gmake [BUILD_OPT=1] For IRIX builds using -n32 flag with pthreads: cvs co -r HCL_157 ns/security cvs co -r HCL_157 ns/coreconf cd ns/coreconf source ./.cshrc gmake USE_N32=1 USE_PTHREADS=1 [BUILD_OPT=1] cd .. cd security gmake USE_N32=1 USE_PTHREADS=1 [BUILD_OPT=1] import gmake USE_N32=1 USE_PTHREADS=1 [BUILD_OPT=1] ************************************************************ ** ** Web site, mailing lists, questions, bug reports ** ************************************************************ You can find information about the Security Libraries at the Hardcore Web site: http://warp/projects/hardcore/ If you have any questions regarding SSL or the HCL libraries, please refer to the following documents: http://twain.mcom.com/developer/security/nss/ssl/index.htm http://twain.mcom.com/developer/security/nss/index.htm There is a mailing list for HCL issues: - hcl: the developers of HCL. Please use BugSplat on scopus (http://scopus/bugsplat) to report bugs. Choose product "Security Library", version "1.5". Here's how/where to get HCL 1.5.7: bits are available at /m/dist/security/19980902 a.k.a. /m/dist/security/HCL_1_57 \\helium\dist\security\19980902 or \\helium\dist\security\HCL_1_57 Here is the list of bugs fixed in HCL 1.5.7: a) Thread safety-related crash in cert lib. b) Thread safety-related problems in NSPR's PL_Arena code. Worked around by surrounding all HCL's PL_Arena calls with a lock/unlock. Applications that make their own calls to NSPR's PL_Arena functions or that use other non-HCL libraries that use PL_Arenas may continue to have thread-safety issues with PL_Arenas. c) Fixed a regression in PKCS#11 in HCL 1.5.6 that caused a crash the first time a server received a bleichenbacker attack ("million question") message. See the HCL 1.5.6 release notes below for the list of known bugs in 1.5.7. Here is a list of the bugs fixed in HCL 1.5.6: 312467 SSL3 uses global pointers for step-down keys, leaks keys 314392 CERT_DestroyCertificate locking code causes nested locking 314571 Memory leak in SSL 314574 HCL Leaks in PKCS #11. 314576 Memory leak in pseudo-prime test in libcrypto 314585 SSL's PR_AcceptRead returns non-aligned PRNetAddr 314592 pkcs5 leaks two memory blocks for each RSA private key op 314596 random number generator causes Unitialized Memory Reads ------------------------------------------------------------------------ HCL 1.5.6 Readme (release notes) ------------------------------------------------------------------------ This file summarizes enhancements, fixed and known bugs in HCL 1.5.6. For detailed instructions on setting up your environment to run the sample code in the samples directory, see Chapter 2, "Getting Started with SSL" (doc/ssl/gtstd.htm) of the SSL Reference (doc/ssl/index.htm). ENHANCEMENTS SINCE NSS 1.5.4 1. SSL returns much more detailed error messages; for details, see doc/ssl/sslerr.htm SSL BUGS FIXED SINCE HCL 1.5.4 1. The "million question" bug in SSL has been fixed. 2. A potential problem (on Unix only) with SSL_InitSessionIDCache has been fixed. The application chooses the directory into which the SSL library places the server session cache. If the application doesn't specify a directory explicitly, the code defaults to using the system default "temporary" directory, which is generally world-writable. The problem that was fixed occured only when the application chose to put the session cache files into a directory writable by untrusted users. If the application put the cache files in a directory that has appropriate limits on access, there was no problem. But if the application put the cache files into a directory that was world writable, it was possible for a rogue program to try to substitute a file it already had open for the server's cache file, and it would succeed some of the time. When it succeeded, it had access to the content of the session ID cache, which enabled it to do various bad things, such as masquerade as one of the remote clients whose session was in the cache. The above problem with the Unix version of SSL_InitSessionIDCachehas been fixed, and rogue programs cannot succeed in substituting their own files for the server's files any more. 3. Client no longer rejects SSL ServerKeyExchange when server's certificate key size is 512 bits. 4. Server no longer crashes in SSL after required client authentication fails. 5. A problem that was causing crashes when multiple threads simultaneously requested client authentication on their respective server sockets has been fixed. 6. The following functions now work with SSL sockets: PR_Write PR_TransmitFile PR_AcceptRead 7. SSL now accepts client hellos that are too long. 8. A problem that produced bad results when multiple threads simultaneously used the random number generator has been fixed. KNOWN BUGS IN HCL 1.5.6: 1. A crash may occur when multiple processes attempt to share a server session ID cache. Because of this bug, an application that handshakes as a server is limited to conducting all SSL calls in a single process. 2. Removing a token does not invalidate the client-side session cache. 3. While a handshake is in progress on an SSL socket, it is not safe for two threads to attempt simultaneous read and write calls (PR_Recv and PR_Send) on that socket. Workaround: ensure that only one thread uses an SSL socket at a time. We expect the above 3 bugs will be fixed in a forthcoming release. SSL v2 issues in HCL 1.5.x: 1. SSL_RedoHandshake only works on SSL3 connections, not SSL2. The SSL2 protocol does not permit additional handshakes on the connection after the first one is done. Ergo, if a client certificate is to be requested in an SSL2 connection, it must be requested on the initial handshake. 2. HCL's SSL2 ignores the setting of the SSL_REQUIRE_CERTIFICATE enable. When SSL_REQUEST_CERTIFICATE is enabled, SSL2 behaves as if SSL_REQUIRE_CERTIFICATE is also enabled, regardless of the actual setting of the SSL_REQUIRE_CERTIFICATE enable. 3. HCL's SSL2 server code doesn't call the bad cert handler callback when the authCert callback returns an error. The ssl2 client code DOES use the badcerthandler callback, but the ssl2 server code does not. This means that if the server's authCert callback returns SECFailure, rejecting the client cert received on an SSL2 connection, the badCerthandler cannot override it. 4. HCL's SSL2 server code never caches the client cert. Consequently, if an SSL2 server is configured to request the client cert, it must ask the client for the client cert on every connection, not just on the first connection in the "session". The SSL2 client must provide the cert in every SSL2 connection that requests it. If the user has set the "ask me every time" option for his certs, he will get prompted a LOT. Item 1 above is not a bug. That's the way ssl2 is defined. Items 2-4 are limitations of our implementation. TomW says client auth in ssl2 was never officially supported (although it is mostly implemented). Recommended workaround for SSL2 issues: a) Don't expect client auth to work for SSL2 users. b) Don't request client auth in the initial handshake. Request it in a subsequent handshake (e.g. set SSL_REQUEST_CERTIFICATE and call SSL_RedoHandshake() on SSL3 connections. This will completely avoid client auth problems with SSL2. For some time now, we've been suggesting that servers request client auth on a second handshake, not the first handshake in the connection. If they do that, then they will never get client certs from ssl2 clients. That is a good thing.