httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: svn commit: r1374640 - /httpd/httpd/branches/2.2.x/STATUS
Date Sun, 19 Aug 2012 17:22:04 GMT
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

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 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.


View raw message