On 02/05/2013 03:11 PM, Jeffrey Walton wrote: > Hi All, > > This relates to 'OpenSSL Security Advisory [05 Feb 2013]' and the > accompanying CVEs. The bulletin did not address combinations of FIPS > Object Module and FIPS Capable Library Combinations. > > Please forgive my ignorance. I don't like to take a lot of latitude or > license on these things. I'm trying to determine (1) what does OpenSSL > recommend/require, and (2) what do I have to [possibly] fix in the > field. > > Is it permissible to use openssl-1.0.1d.tar.gz with > openssl-fips-2.0.1.tar.gz? Or should we be using > openssl-fips-2.0.2.tar.gz? > > If we are only using cryptography from libcrypto.a - and not ssl/tls > from libssl.a - is openssl-1.0.1c.tar.gz still permissible to use?
There are two separate issues here, that of FIPS 140-2 validation and that of defense against malicious compromise. The two are quite distinct and in fact mutually exclusive to a significant extent. The #1747 validation is applicable to any of openssl-fips-2.0.tar.gz, openssl-fips-2.0.1.tar.gz, openssl-fips-2.0.2.tar.gz and (soon) openssl-fips-2.0.3.tar.gz when used with any version of OpenSSL 1.0.1. If your primary objective is satisfying a requirement for FIPS 140-2 validated cryptography then use any of those combinations and you're golden. But... The mitigation of the "Lucky 13" TLS vulnerability recently added to OpenSSL 1.0.1d is unfortunately only partially effective when OpenSSL is built with the "fips" option to include the OpenSSL FIPS Object Module, and the FIPS mode of operation is enabled. That is because properly addressing the timing issues would require the introduction of low level functions to the FIPS module, but modifications to validated cryptography are not allowed(*). So a partial mitigation was implemented in OpenSSL, but that is known to be less than fully satisfactory and has not been tested for efficacy. When FIPS mode is enabled in a "FIPS capable" OpenSSL, including 1.0.1d, the "Lucky 13" vulnerability should be considered still present. If your primary objective is security, in the real-world sense of protection from malicious compromise, use OpenSSL 1.0.1d but do *not* use the OpenSSL FIPS Object Module, or at least don't enable FIPS mode. Unfortunately the environments where the FIPS module is currently used will typically be those environments where such use is mandated. By the very nature of the FIPS 140-2 validation process validated cryptography will always be less secure than the unvalidated equivalent. Note this is true not only of the #1747 module but also for all validated cryptography that is based on OpenSSL (which is most validated cryptography). Even worse, Paterson and AlFardan note in their paper that all current TLS implementations will exhibit the same vulnerability, and so this problem is likely universal for all validated cryptography that is used for TLS. -Steve M. (*)Technically the necessary code changes could be added to the validation via a "maintenance letter" by retesting each of the 50 plus platforms. That would cost over a hundred thousand dollars in test lab fees alone and would require man-months of labor. That is not going to happen. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
