On May 29, 2010, at 6:02 AM, Steve Marquess wrote:
> Dr Stephen Henson wrote: >> On 25/05/2010 13:45, Joe Orton wrote: >> >>> I'd like to drop support for versions of OpenSSL older than 1.0 in the >>> trunk mod_ssl. We have 200+ lines of compat macro junk and still six >>> different compiler warnings remain in a trunk build against 1.0.0. >>> >>> pro: simplify code: remove ssl_toolkit_compat.h and all compat macro mess >>> which litters the code >>> >>> pro: simplify testing: no longer have to test/worry about regressing builds >>> against N subtly different versions of the OpenSSL API all >>> >>> pro: can drop the internal CRL revocation code in favour of OpenSSL's >>> >>> pro: users will be "encouraged" to upgrade to a modern OpenSSL which has >>> secure TLS reneg >>> >>> con: trunk/2.3 won't build on all platforms/distros which ship natively >>> with OpenSSL < 1.0 (duh) >>> >>> con: I presume this will mean dropping support for the RSA/... toolkits, if >>> they even work still, which I very much doubt I have several times requested access to sslc from RSA, for the stated purpose of testing Apache integration, and have always been summarily denied. Can it. >>> So... love/hate? Deprecating obsolete libraries is a good thing, especially if there is a compelling replacement. I think this goes hand in hand with what operating system versions we will be targeting for 2.4. We should inventory which versions of the libraries are offered on each and then make the decision whether to accomodate: * Windows: none * Mac OS X 10.6: OpenSSL 0.9.8l 5 Nov 2009 * FreeBSD 6.4-STABLE: OpenSSL 0.9.7e-p1 25 Oct 2004 * FreeBSD 7.2-STABLE: OpenSSL 0.9.8e 23 Feb 2007 * FreeBSD 8-STABLE: OpenSSL 0.9.8k 25 Mar 2009 * OpenBSD 4.6: OpenSSL 0.9.8k 25 Mar 2009 * Solaris 10: 0.9.7 with backports... don't recall what's in the Coolstack but someone else may be able to tell us. * Sunfreeware.com: 1.0.0 and 0.9.7g, with both Apache 2.0.59 and 2.2.15 built against 1.0.0 * Red Hat 5: 0.9.8b with backports * Red Hat 4: 0.9.7 with backports * Ubuntu 10.04: OpenSSL 0.9.8k 25 Mar 2009 ... It seems that 0.9.8 is still fairly prevalent, and dropping support for it in 2.3/2.4 might hurt adoption in the near term. >> con: means FIPS 140-2 support would be dropped too. FIPS 140-2 is not >> supported >> in 1.0.0, only 0.9.8 (well 0.9.7 too but we recommend everyone use the 1.2 >> module with 0.9.8 if possible). > > Belated comment: FIPS 140-2 is used with Apache, both directly as open source > and as vendor supplied binaries. FIPS 140-2 is required in U.S. DoD and > federal government environments (where I do much of my consulting work). > That requirement has been in place for years but is now actually being > enforced. Many users would like to upgrade but can't due to that requirement. > > Until a new FIPS validation is available for OpenSSL 1.0.0 it would IMHO be a > Very Bad Thing to drop support for 0.9.8. Such a validation will require > commercial or government sponsorship, as did the earlier validations, plus a > long lead time. We get occasional expressions of interest but nothing solid > yet, but I'm confident it will happen eventually. In the meantime, dropping > support for 0.9.8 will force many government sector Apache users elsewhere. Please note that no released version of Apache knows how to put OpenSSL into FIPS mode. When your Many Users run Apache in a situation with FIPS requirements, which and whose patches do they use? Work on FIPS integration at Apache itself stalled in 2007: http://svn.apache.org/viewvc/httpd/sandbox/gaithersburg/README-FIPS?view=log and the last commit message: "In an effort to dissuade users from adopting this tree as 'ready for openssl fips', rename this repository. Gaithersburg happens to be one of the two campuses of NIST who issues the FIPS standards. When this is ready to be merged to httpd and apr, it's ready. Not before, there is a security policy document for openssl's implementation which must be adhered to." Using FIPS 140-2 certified hardware to protect the RSA private keys for websites generally happens mostly transparently through OpenSSL Engines, of which I can tell you that one, CHIL, works perfectly fine in 1.0.0. S. -- Sander Temme [email protected] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
