The 0.9.8[no] SSLv3 client code sends the SCSV cipher even when built
with "no-tlsext" and is then unable to process the server response if
the server returns tls extensions.
It is my impression that enabling tls extensions breaks binary
compatibility, so I cannot replace a "no-tlsext" shared library with
one that support extensions without re-compiling all the clients. So,
some legacy systems still get "no-tlsext" libraries until we move
everyone to 1.0.0.
The SSL client should not solicit server behaviour it does not support.
Patch below.
--- ssl/ssl_lib.c 2010-02-17 14:43:08.601690964 -0500
+++ ssl/ssl_lib.c 2010-09-02 13:19:18.401865197 -0400
@@ -1299,6 +1299,8 @@
j = put_cb ? put_cb(c,p) : ssl_put_cipher_by_char(s,c,p);
p+=j;
}
+
+#ifndef OPENSSL_NO_TLSEXT
/* If p == q, no ciphers and caller indicates an error. Otherwise
* add SCSV if not renegotiating.
*/
@@ -1310,10 +1312,11 @@
};
j = put_cb ? put_cb(&scsv,p) :
ssl_put_cipher_by_char(s,&scsv,p);
p+=j;
-#ifdef OPENSSL_RI_DEBUG
+# ifdef OPENSSL_RI_DEBUG
fprintf(stderr, "SCSV sent by client\n");
-#endif
+# endif
}
+#endif /* OPENSSL_NO_TLSEXT */
return(p-q);
}
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
