PR: 2178

[openssl.git] / CHANGES

diff --git a/CHANGES b/CHANGES
index 2f7f79e526debd7fdb6f6e6d980f08c4c7d6ae6c..178a68dbda8cc180a3d9472ff28b467fdac9adcb 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -843,7 +843,16 @@
   *) Change 'Configure' script to enable Camellia by default.
      [NTT]
 
- Changes between 0.9.8l (?) and 0.9.8m (?)  [xx XXX xxxx]
+ Changes between 0.9.8l and 0.9.8m  [25 Feb 2010]
+
+  *) Fix X509_STORE locking: Every 'objs' access requires a lock (to
+     accommodate for stack sorting, always a write lock!).
+     [Bodo Moeller]
+
+  *) On some versions of WIN32 Heap32Next is very slow. This can cause
+     excessive delays in the RAND_poll(): over a minute. As a workaround
+     include a time check in the inner Heap32Next loop too.
+     [Steve Henson]
 
   *) The code that handled flushing of data in SSL/TLS originally used the
      BIO_CTRL_INFO ctrl to see if any data was pending first. This caused
@@ -872,7 +881,7 @@
      [Bodo Moeller]
 
   *) Add option SSL_OP_LEGACY_SERVER_CONNECT which will allow clients to
-     connect (but not renegotiate) with servers which do not support RI.
+     connect and renegotiate with servers which do not support RI.
      Until RI is more widely deployed this option is enabled by default.
      [Steve Henson]
 
@@ -880,14 +889,14 @@
      [Steve Henson]
 
   *) If client attempts to renegotiate and doesn't support RI respond with
-     a no_renegotiation alert as required by draft-ietf-tls-renegotiation.
-     Some renegotiating TLS clients will continue a connection gracefully
-     when they receive the alert. Unfortunately OpenSSL mishandled
-     this alert and would hang waiting for a server hello which it will never
-     receive. Now we treat a received no_renegotiation alert as a fatal 
-     error. This is because applications requesting a renegotiation might well
-     expect it to succeed and would have no code in place to handle the server
-     denying it so the only safe thing to do is to terminate the connection.
+     a no_renegotiation alert as required by RFC5746.  Some renegotiating
+     TLS clients will continue a connection gracefully when they receive
+     the alert. Unfortunately OpenSSL mishandled this alert and would hang
+     waiting for a server hello which it will never receive. Now we treat a
+     received no_renegotiation alert as a fatal error. This is because
+     applications requesting a renegotiation might well expect it to succeed
+     and would have no code in place to handle the server denying it so the
+     only safe thing to do is to terminate the connection.
      [Steve Henson]
 
   *) Add ctrl macro SSL_get_secure_renegotiation_support() which returns 1 if
@@ -899,10 +908,9 @@
      the updated NID creation version. This should correctly handle UTF8.
      [Steve Henson]
 
-  *) Implement draft-ietf-tls-renegotiation-03. Re-enable
-     renegotiation but require the extension as needed. Unfortunately,
-     SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION turns out to be a
-     bad idea. It has been replaced by
+  *) Implement RFC5746. Re-enable renegotiation but require the extension
+     as needed. Unfortunately, SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION
+     turns out to be a bad idea. It has been replaced by
      SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION which can be set with
      SSL_CTX_set_options(). This is really not recommended unless you
      know what you are doing.