On 18.8.12 21:51, William A. Rowe Jr. wrote: >> to drop the #ifndef around SSL_PROTOCOL_SSLV2 in ssl_private.h, >> this should also make some of the other "#if[n]def >> OPENSSL_NO_SSL2" >> encapsulations unnecessary. >> + [wrowe] agreed the patch was wrong, the #ifdef needed to be >> moved >> + up four lines. Behavior is now correct in patch .2 >> + Disagree about retaining SSL_PROTOCOL_SSLV2; this is >> one >> + of the most basic design patterns which exists to >> ensure >> + that we don't have some lingering code which is still >> + attempting to pursue SSLV2 games, not to mention that >> + the various macros and functions in those blocks may >> + simply disappear disappear in an OPENSSL_NO_SSL2 >> build. >> + Bad idea, it helps us catch current and future >> problems.
After a closer look at the mechanics of OPENSSL_NO_SSL2 in OpenSSL, I think there's a misunderstanding of how OpenSSL exposes this compile-time option to applications linking against libssl. OpenSSL itself only defines OPENSSL_NO_SSL2 in the following case (openssl/ssl.h): > #if (defined(OPENSSL_NO_RSA) || defined(OPENSSL_NO_MD5)) && > !defined(OPENSSL_NO_SSL2) > #define OPENSSL_NO_SSL2 > #endif (ssl.h is not customized by OpenSSL's Configure script, AFAICT you would have to call "openssl version -f" and look for any flags set at compile time.) I.e., unless mod_ssl is explicitly compiled with -DOPENSSL_NO_SSL2 (set through CPPFLAGS/CFLAGS), an #ifdef OPENSSL_NO_SSL2 has no effect, and the blocks enclosed with #ifndef OPENSSL_NO_SSL2 will get included, irrespective of how OpenSSL has been compiled. > the flexibility to disable a particular cipher in light of exploit > research in the very fresh openssl code base makes this patch pretty > critical to release for legacy, as well as stable. I'm not sure what exactly you're referring to - is there new research showing that it's more than a DoS issue (which is what http://www.openssl.org/news/secadv_20120510.txt currently states)? Generally speaking, users of OpenSSL 1.0.1 (and 1.0.1a/1.0.1b) should upgrade their OpenSSL libraries... I would consider it rather awkward to recommend them an upgrade to httpd 2.2.23, only for being able to disable TLS 1.1/1.2. Kaspar
