bugfix: handle HelloRequest received during handshake correctly

[openssl.git] / CHANGES

diff --git a/CHANGES b/CHANGES
index 3b467094cba307d22bf4835bd68904ed3f18506d..be6cfb184aeabe9b68a44e22752dc18b28cc90a2 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -12,6 +12,52 @@
          *) applies to 0.9.6a/0.9.6b/0.9.6c and 0.9.7
          +) applies to 0.9.7 only
 
+  *) Avoid infinite loop in ssl3_get_message (ssl/s3_both.c) if a
+     client receives HelloRequest while in a handshake.
+     [Bodo Moeller; bug noticed by Andy Schneider <andy.schneider@bjss.co.uk>]
+
+  +) New function SSL_renegotiate_pending().  This returns true once
+     renegotiation has been requested (either SSL_renegotiate() call
+     or HelloRequest/ClientHello receveived from the peer) and becomes
+     false once a handshake has been completed.
+     (For servers, SSL_renegotiate() followed by SSL_do_handshake()
+     sends a HelloRequest, but does not ensure that a handshake takes
+     place.  SSL_renegotiate_pending() is useful for checking if the
+     client has followed the request.)
+     [Bodo Moeller]
+
+  +) New SSL option SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION.
+     By default, clients may request session resumption even during
+     renegotiation (if session ID contexts permit); with this option,
+     session resumption is possible only in the first handshake.
+     [Bodo Moeller]
+
+  *) Bugfix in ssl3_accept (ssl/s3_srvr.c): Case SSL3_ST_SW_HELLO_REQ_C
+     should end in 'break', not 'goto end' which circuments various
+     cleanups done in state SSL_ST_OK.   But session related stuff
+     must be disabled for SSL_ST_OK in the case that we just sent a
+     HelloRequest.
+
+     Also avoid some overhead by not calling ssl_init_wbio_buffer()
+     before just sending a HelloRequest.
+     [Bodo Moeller, Eric Rescorla <ekr@rtfm.com>]
+
+  *) Fix ssl/s3_enc.c, ssl/t1_enc.c and ssl/s3_pkt.c so that we don't
+     reveal whether illegal block cipher padding was found or a MAC
+     verification error occured.  (Neither SSLerr() codes nor alerts
+     are directly visible to potential attackers, but the information
+     may leak via logfiles.)
+
+     Similar changes are not required for the SSL 2.0 implementation
+     because the number of padding bytes is sent in clear for SSL 2.0,
+     and the extra bytes are just ignored.  However ssl/s2_pkt.c
+     failed to verify that the purported number of padding bytes is in
+     the legal range.
+     [Bodo Moeller]
+
+  +) Add some demos for certificate and certificate request creation.
+     [Steve Henson]
+
   +) Make maximum certificate chain size accepted from the peer application
      settable (SSL*_get/set_max_cert_list()), as proposed by
      "Douglas E. Engert" <deengert@anl.gov>.