зеркало из https://github.com/mozilla/gecko-dev.git
285 строки
10 KiB
Plaintext
285 строки
10 KiB
Plaintext
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.
|
|
|
|
- <platform> directories: where <platform> is of the form
|
|
<os-name><os-version>[_<compiler>][_<implementation strategy>]_<DBG/OPT>.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 <platform> 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.
|
|
|