Re: [openssl-users] Using FIPS mode and modifying apps
On Mon, 26 Jan 2015 22:35:12 -0500 Tom Francis thomas.francis...@pobox.com wrote: This is a bad idea. It can generally be done, and it’s probably not even too hard (for some uses, anyway). But it’s a bad idea. Here’s why: Thanks for the detailed comments. I understand the concerns, although there's one thing I do not see clearly, that is: 2) Applications that don’t know they’re operating in FIPS mode may attempt to use algorithms that are disallowed in FIPS mode, but using an API that will actually succeed. How could this happen ? Do you have a practical use case ? Wouldn't OpenSSL in FIPS mode prevent the use of such algorithm in the first place ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On 01/28/2015 08:31 AM, jone...@teksavvy.com wrote: ... We have not done any validations that satisfy the various new requirements introduced in late 2013 and early 2014. New validations are very expensive, in dollars, time, and grief, and we don't have the necessary financial backing. Something I don't understand. Does validation prevent any software development ? Eg. why not develop a newer version that is not validated (until further notice) but will include for instance the automatic library load that would perform transparently all the FIPS checks ? ... Why should we? Frankly the FIPS 140-2 stuff is of interest to only a small portion of the overall OpenSSL user base: basically just those commercial vendors who sell to the U.S. government market. The FIPS validated software itself is necessarily inferior to the stock OpenSSL by any real world metric (security, performance, maintainability and usability), and so has no value for the rest of the world or the private sector in the U.S. The fully validated module (OpenSSL FIPS Object Module) is at least of use to all those commercial vendors selling to the USG and DoD; speculative code that would make it easier for vendors like you to pursue private proprietary validations would be of interest to a far smaller subset. We have enough demands on our limited resources as it is to expend them on such a limited constituency. -Steve M. -- 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 gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Jan 28, 2015, at 8:47 AM, Dr. Stephen Henson st...@openssl.org wrote: On Wed, Jan 28, 2015, jone...@teksavvy.com wrote: On Mon, 26 Jan 2015 22:35:12 -0500 Tom Francis thomas.francis...@pobox.com wrote: Thanks for the detailed comments. I understand the concerns, although there's one thing I do not see clearly, that is: 2) Applications that don???t know they???re operating in FIPS mode may attempt to use algorithms that are disallowed in FIPS mode, but using an API that will actually succeed. How could this happen ? Do you have a practical use case ? Wouldn't OpenSSL in FIPS mode prevent the use of such algorithm in the first place ? OpenSSL does prevent the use of non-FIPS algorithms in FIPS mode but applications don't always cleanly handle it. If the application uses TLS then it should be OK as non-FIPS ciphersuites are automatically blocked. A possible gotcha is use of private keys encrypted using the old MD5 PBE algorithm. If the application uses algorithms directly via for example EVP_DigestInit_ex() then things are different. A non-FIPS application might never see an error from EVP_DigestInit_ex() and not handle it properly (e.g. ignoring the return value). This will cause a hard failure later on. Even if an application does check return values it might regard an error return from EVP_DigestInit_ex() as a fatal error (it sometimes is: e.g. memory allocation failure): it is unlikely to retry with a different algorithm. The correct thing to do is never attempt to use the non-FIPS algorithm in the first place. What that measn in practice is that while some applications will just work when FIPS mode is enabled, others need to be modified to correctly handle FIPS. Actually, I was thinking of the 1.x FIPS module, and OpenSSL 0.9.8, where OpenSSL would prevent disallowed algorithms from being used, but only if you used the EVP interfaces. You could, for example, invoke MD5 directly. Did that change with 2.x? (it’s not something I paid much attention to, as I always used EVP, anyway). It’s also my understanding that the private APIs could still be used to bypass the FIPS mode algorithm checks, and that some applications may be using those. TOM Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Wed, Jan 28, 2015, Tom Francis wrote: Actually, I was thinking of the 1.x FIPS module, and OpenSSL 0.9.8, where OpenSSL would prevent disallowed algorithms from being used, but only if you used the EVP interfaces. You could, for example, invoke MD5 directly. Did that change with 2.x? (it???s not something I paid much attention to, as I always used EVP, anyway). It???s also my understanding that the private APIs could still be used to bypass the FIPS mode algorithm checks, and that some applications may be using those. With 2.0 the low level calls are blocked in FIPS mode and you have to use EVP. The blocking in OpenSSL is designed to block *accidental* calls to unapproved algorithms in FIPS mode. An application can decide to bypass those checks if it wants to (for example some usages of unapproved algorithms are considered acceptable in FIPS mode) with appropriate calls. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Tue, 27 Jan 2015 14:13:57 -0500 Steve Marquess marqu...@openssl.com wrote: The user guide documents that correctly. For the OpenSSL FIPS Object Module 2.0 (#1747) the FIPS mode of operation is enabled with FIPS_mode_set(). There is no library startup; you keep confusing past validations with new ones. OK. Note that we would update that existing module to comply with the new I.G. 9.10 guidance, but that falls in the class of changes that are not permitted under the change letter update process (similarly, we weren't allowed to update the module to address security vulnerabilities such as Lucky 13). Yes, FIPS is what it is. I'm short of describing words now, and I prefer not to search too long :-) We have not done any validations that satisfy the various new requirements introduced in late 2013 and early 2014. New validations are very expensive, in dollars, time, and grief, and we don't have the necessary financial backing. Something I don't understand. Does validation prevent any software development ? Eg. why not develop a newer version that is not validated (until further notice) but will include for instance the automatic library load that would perform transparently all the FIPS checks ? In our case, our system as a whole will be validated. And that includes OpenSSL, as well as anything else that's relevant to FIPS, including stickers on the units. OpenSSL will be validated anyways. We are looking at adding the automatic load hence the running of FIPS tests at library load time. But then, this might change depending on the assessment of other FIPS-aware modifications to popular Open Source packages. Otherwise, if they (most) have already FIPS mode options, then we would add the automatic hooks to OpenSSL. And the unit will be sent to the consultants who will run their SSL tests and others, and then to the NIST labs, as such. Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Mon, 26 Jan 2015 22:35:12 -0500 Tom Francis thomas.francis...@pobox.com wrote: This is a bad idea. It can generally be done, and it’s probably not even too hard (for some uses, anyway). But it’s a bad idea. Here’s why: Thanks for the detailed comments. I understand the concerns, although there's one thing I do not see clearly, that is: 2) Applications that don’t know they’re operating in FIPS mode may attempt to use algorithms that are disallowed in FIPS mode, but using an API that will actually succeed. How could this happen ? Do you have a practical use case ? Wouldn't OpenSSL in FIPS mode prevent the use of such algorithm in the first place ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Wed, Jan 28, 2015, jone...@teksavvy.com wrote: On Mon, 26 Jan 2015 22:35:12 -0500 Tom Francis thomas.francis...@pobox.com wrote: Thanks for the detailed comments. I understand the concerns, although there's one thing I do not see clearly, that is: 2) Applications that don???t know they???re operating in FIPS mode may attempt to use algorithms that are disallowed in FIPS mode, but using an API that will actually succeed. How could this happen ? Do you have a practical use case ? Wouldn't OpenSSL in FIPS mode prevent the use of such algorithm in the first place ? OpenSSL does prevent the use of non-FIPS algorithms in FIPS mode but applications don't always cleanly handle it. If the application uses TLS then it should be OK as non-FIPS ciphersuites are automatically blocked. A possible gotcha is use of private keys encrypted using the old MD5 PBE algorithm. If the application uses algorithms directly via for example EVP_DigestInit_ex() then things are different. A non-FIPS application might never see an error from EVP_DigestInit_ex() and not handle it properly (e.g. ignoring the return value). This will cause a hard failure later on. Even if an application does check return values it might regard an error return from EVP_DigestInit_ex() as a fatal error (it sometimes is: e.g. memory allocation failure): it is unlikely to retry with a different algorithm. The correct thing to do is never attempt to use the non-FIPS algorithm in the first place. What that measn in practice is that while some applications will just work when FIPS mode is enabled, others need to be modified to correctly handle FIPS. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On 01/28/2015 08:31 AM, jone...@teksavvy.com wrote: ... We have not done any validations that satisfy the various new requirements introduced in late 2013 and early 2014. New validations are very expensive, in dollars, time, and grief, and we don't have the necessary financial backing. Something I don't understand. Does validation prevent any software development ? Eg. why not develop a newer version that is not validated (until further notice) but will include for instance the automatic library load that would perform transparently all the FIPS checks ? ... Why should we? Frankly the FIPS 140-2 stuff is of interest to only a small portion of the overall OpenSSL user base: basically just those commercial vendors who sell to the U.S. government market. The FIPS validated software itself is necessarily inferior to the stock OpenSSL by any real world metric (security, performance, maintainability and usability), and so has no value for the rest of the world or the private sector in the U.S. The fully validated module (OpenSSL FIPS Object Module) is at least of use to all those commercial vendors selling to the USG and DoD; speculative code that would make it easier for vendors like you to pursue private proprietary validations would be of interest to a far smaller subset. We have enough demands on our limited resources as it is to expend them on such a limited constituency. -Steve M. -- 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 gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Jan 28, 2015, at 8:47 AM, Dr. Stephen Henson st...@openssl.org wrote: On Wed, Jan 28, 2015, jone...@teksavvy.com wrote: On Mon, 26 Jan 2015 22:35:12 -0500 Tom Francis thomas.francis...@pobox.com wrote: Thanks for the detailed comments. I understand the concerns, although there's one thing I do not see clearly, that is: 2) Applications that don???t know they???re operating in FIPS mode may attempt to use algorithms that are disallowed in FIPS mode, but using an API that will actually succeed. How could this happen ? Do you have a practical use case ? Wouldn't OpenSSL in FIPS mode prevent the use of such algorithm in the first place ? OpenSSL does prevent the use of non-FIPS algorithms in FIPS mode but applications don't always cleanly handle it. If the application uses TLS then it should be OK as non-FIPS ciphersuites are automatically blocked. A possible gotcha is use of private keys encrypted using the old MD5 PBE algorithm. If the application uses algorithms directly via for example EVP_DigestInit_ex() then things are different. A non-FIPS application might never see an error from EVP_DigestInit_ex() and not handle it properly (e.g. ignoring the return value). This will cause a hard failure later on. Even if an application does check return values it might regard an error return from EVP_DigestInit_ex() as a fatal error (it sometimes is: e.g. memory allocation failure): it is unlikely to retry with a different algorithm. The correct thing to do is never attempt to use the non-FIPS algorithm in the first place. What that measn in practice is that while some applications will just work when FIPS mode is enabled, others need to be modified to correctly handle FIPS. Actually, I was thinking of the 1.x FIPS module, and OpenSSL 0.9.8, where OpenSSL would prevent disallowed algorithms from being used, but only if you used the EVP interfaces. You could, for example, invoke MD5 directly. Did that change with 2.x? (it’s not something I paid much attention to, as I always used EVP, anyway). It’s also my understanding that the private APIs could still be used to bypass the FIPS mode algorithm checks, and that some applications may be using those. TOM Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Wed, Jan 28, 2015, Tom Francis wrote: Actually, I was thinking of the 1.x FIPS module, and OpenSSL 0.9.8, where OpenSSL would prevent disallowed algorithms from being used, but only if you used the EVP interfaces. You could, for example, invoke MD5 directly. Did that change with 2.x? (it???s not something I paid much attention to, as I always used EVP, anyway). It???s also my understanding that the private APIs could still be used to bypass the FIPS mode algorithm checks, and that some applications may be using those. With 2.0 the low level calls are blocked in FIPS mode and you have to use EVP. The blocking in OpenSSL is designed to block *accidental* calls to unapproved algorithms in FIPS mode. An application can decide to bypass those checks if it wants to (for example some usages of unapproved algorithms are considered acceptable in FIPS mode) with appropriate calls. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On 01/26/2015 06:21 PM, jone...@teksavvy.com wrote: On Fri, 16 Jan 2015 10:16:48 -0500 Steve Marquess marqu...@openssl.com wrote: On 01/15/2015 05:52 AM, Marcus Meissner wrote: On Linux usually triggered by /proc/sys/crypto/fips_enabled containing 1 or the environment variable OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and Redhat, which do not use the container blob). That is (presumably) true for the proprietary RH and SUSE distros, not so for the open source based OpenSSL FIPS Object Module or other Linux distros. I'm afraid it does not come across clear to me. So, maybe the following pondering is relevant - or not. Basically, I'm looking at how to integrate a FIPS-enabled OpenSSL that will be used by some common Open Sources applications, as well as a 3rd party application (with source code provided). Tom Francis nailed the answer to this one. We did design the FIPS module + FIPS capable OpenSSL combination to make it possible to have a system wide FIPS mode capability, but that presumes that the system maintainer (i.e. OS distribution maintainer) has done the review and modification of each application that uses cryptography to make sure it is compatible with the many restrictions of FIPS mode. So, does your comment mean that the paying versions of Red Hat and SuSE (proprietary) have open source applications modified to at least include the FIPS_mode_set() call ? Why would these releases be different in FIPS SSL 'power-up' POST checks when compared to regular free releases ? That is indeed the assumption: that commercial versions of RH and SuSE have modified all impacted OSS applications to operate in FIPS mode. If they haven't they are deceiving their customers and the U.S. government. Note that such modifications are non-trivial for some applications, for instance OpenSSH. If I compare with GnuTLS that our product also uses, and with which it will also go to certification, its FIPS mode is completly transparent, with FIPS checks done on library load. Can't help you there as I know nothing of GnuTLS. But, applications using GnuTLS will face exactly the same problem; if they were not designed or modified to operate in FIPS mode you're probably going to have undesirable outcomes. Based on the discussion in 'The I.G. 9.5 Issue', I took a look at 'Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program', January 15 2015 release. In section 9.10 it states:... Please read the first two sentences on that web page, right at the top. -Steve M. -- 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 gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On 01/26/2015 06:21 PM, jone...@teksavvy.com wrote: On Fri, 16 Jan 2015 10:16:48 -0500 Steve Marquess marqu...@openssl.com wrote: On 01/15/2015 05:52 AM, Marcus Meissner wrote: On Linux usually triggered by /proc/sys/crypto/fips_enabled containing 1 or the environment variable OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and Redhat, which do not use the container blob). That is (presumably) true for the proprietary RH and SUSE distros, not so for the open source based OpenSSL FIPS Object Module or other Linux distros. I'm afraid it does not come across clear to me. So, maybe the following pondering is relevant - or not. Basically, I'm looking at how to integrate a FIPS-enabled OpenSSL that will be used by some common Open Sources applications, as well as a 3rd party application (with source code provided). Tom Francis nailed the answer to this one. We did design the FIPS module + FIPS capable OpenSSL combination to make it possible to have a system wide FIPS mode capability, but that presumes that the system maintainer (i.e. OS distribution maintainer) has done the review and modification of each application that uses cryptography to make sure it is compatible with the many restrictions of FIPS mode. So, does your comment mean that the paying versions of Red Hat and SuSE (proprietary) have open source applications modified to at least include the FIPS_mode_set() call ? Why would these releases be different in FIPS SSL 'power-up' POST checks when compared to regular free releases ? That is indeed the assumption: that commercial versions of RH and SuSE have modified all impacted OSS applications to operate in FIPS mode. If they haven't they are deceiving their customers and the U.S. government. Note that such modifications are non-trivial for some applications, for instance OpenSSH. If I compare with GnuTLS that our product also uses, and with which it will also go to certification, its FIPS mode is completly transparent, with FIPS checks done on library load. Can't help you there as I know nothing of GnuTLS. But, applications using GnuTLS will face exactly the same problem; if they were not designed or modified to operate in FIPS mode you're probably going to have undesirable outcomes. Based on the discussion in 'The I.G. 9.5 Issue', I took a look at 'Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program', January 15 2015 release. In section 9.10 it states:... Please read the first two sentences on that web page, right at the top. -Steve M. -- 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 gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
Steve Marquess marqu...@openssl.comwrote on 01/27/15 09:18: Thank you (and Tom) for your comments - much appreciated. Tom Francis nailed the answer to this one. We did design the FIPS module + FIPS capable OpenSSL combination to make it possible to have a system wide FIPS mode capability, but that presumes that the system maintainer (i.e. OS distribution maintainer) has done the review and modification of each application that uses cryptography to make sure it is compatible with the many restrictions of FIPS mode. Yes, I understand the concern. Does this mean that the FIPS checks will be done today on OpenSSL library startup w/o the need for an application to use FIPS_mode_set() ? I'm asking since the OpenSSL FIPS User Guide 2.0 only mentions using FIPS_mode_set() (and FIPS_selftest()). Might have to do with your comment below. That is indeed the assumption: that commercial versions of RH and SuSE have modified all impacted OSS applications to operate in FIPS mode. If they haven't they are deceiving their customers and the U.S. government. I see. There is a set of SuSE OpenSSH FIPS patches from 9 months ago, though. Please read the first two sentences on that web page, right at the top. OK! Regarding the second sentence :) ... what is the current status ? Is OpenSSL transparently executing FIPS checks when in FIPS mode ? And, why would there be any validation (as opposed to functional tests) to be done since these checks are the same as they were before I presume, just done automatically this time around. Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On 01/27/2015 11:09 AM, jonetsu wrote: Steve Marquess marqu...@openssl.comwrote on 01/27/15 09:18: Thank you (and Tom) for your comments - much appreciated. Tom Francis nailed the answer to this one. We did design the FIPS module + FIPS capable OpenSSL combination to make it possible to have a system wide FIPS mode capability, but that presumes that the system maintainer (i.e. OS distribution maintainer) has done the review and modification of each application that uses cryptography to make sure it is compatible with the many restrictions of FIPS mode. Yes, I understand the concern. Does this mean that the FIPS checks will be done today on OpenSSL library startup w/o the need for an application to use FIPS_mode_set() ? I'm asking since the OpenSSL FIPS User Guide 2.0 only mentions using FIPS_mode_set() (and FIPS_selftest()). Might have to do with your comment below. The user guide documents that correctly. For the OpenSSL FIPS Object Module 2.0 (#1747) the FIPS mode of operation is enabled with FIPS_mode_set(). There is no library startup; you keep confusing past validations with new ones. Note that we would update that existing module to comply with the new I.G. 9.10 guidance, but that falls in the class of changes that are not permitted under the change letter update process (similarly, we weren't allowed to update the module to address security vulnerabilities such as Lucky 13). That is indeed the assumption: that commercial versions of RH and SuSE have modified all impacted OSS applications to operate in FIPS mode. If they haven't they are deceiving their customers and the U.S. government. I see. There is a set of SuSE OpenSSH FIPS patches from 9 months ago, though. Please read the first two sentences on that web page, right at the top. OK! Regarding the second sentence :) ... what is the current status ? We have not done any validations that satisfy the various new requirements introduced in late 2013 and early 2014. New validations are very expensive, in dollars, time, and grief, and we don't have the necessary financial backing. -Steve M. -- 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 gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Fri, 16 Jan 2015 10:16:48 -0500
Steve Marquess marqu...@openssl.com wrote:
On 01/15/2015 05:52 AM, Marcus Meissner wrote:
On Linux usually triggered by /proc/sys/crypto/fips_enabled
containing 1 or the environment variable
OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and
Redhat, which do not use the container blob).
That is (presumably) true for the proprietary RH and SUSE distros,
not so for the open source based OpenSSL FIPS Object Module or other
Linux distros.
I'm afraid it does not come across clear to me. So, maybe the
following pondering is relevant - or not. Basically, I'm looking at
how to integrate a FIPS-enabled OpenSSL that will be used by some
common Open Sources applications, as well as a 3rd party application
(with source code provided).
So, does your comment mean that the paying versions of Red
Hat and SuSE (proprietary) have open source applications modified to at
least include the FIPS_mode_set() call ? Why would these releases be
different in FIPS SSL 'power-up' POST checks when compared to regular
free releases ?
If I compare with GnuTLS that our product also uses, and with which it
will also go to certification, its FIPS mode is completly transparent,
with FIPS checks done on library load.
Based on the discussion in 'The I.G. 9.5 Issue', I took a look at
'Implementation Guidance for FIPS PUB 140-2 and the Cryptographic
Module Validation Program', January 15 2015 release. In section 9.10
it states:
The power-on self-tests of the module shall be triggered from
within that library function or code block. This execution paradigm
satisfies AS09.08 and AS09.09 for a validated module.
This would make it OK for OpenSSL to automatically run the FIPS checks
when an application loads the library. Are the issues noted in the
'I.G. 9.5 Issue' still relevant ? For instance, the first paragraph
of Q4 refers to an application using the library before the library
itself has finished doing the FIPS POST checks. Hmmm. without
knowing the details I must say, it 'looks like' GnuTLS has solved this
problem - or will it simply fail certification lab testing ?
Further in the CMVP IG, there is mention that ('DEP' is a default
entry point) :
The presence of a library DEP forces the OS loader to call the DEP
when it loads the library on behalf of the application linking it.
The DEP is executed automatically and independently of the
application code before the OS loader hands control back to the
application. The OS loader utilizes a standard mechanism for
invoking the DEP, which is agnostic of the library programming
interface and completely independent of the application code.
Wouldn't this mechanism be solving the problems raised in Q4 ?
Regards.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Jan 26, 2015, at 6:21 PM, jone...@teksavvy.com wrote: On Fri, 16 Jan 2015 10:16:48 -0500 Steve Marquess marqu...@openssl.com wrote: On 01/15/2015 05:52 AM, Marcus Meissner wrote: On Linux usually triggered by /proc/sys/crypto/fips_enabled containing 1 or the environment variable OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and Redhat, which do not use the container blob). That is (presumably) true for the proprietary RH and SUSE distros, not so for the open source based OpenSSL FIPS Object Module or other Linux distros. I'm afraid it does not come across clear to me. So, maybe the following pondering is relevant - or not. Basically, I'm looking at how to integrate a FIPS-enabled OpenSSL that will be used by some common Open Sources applications, as well as a 3rd party application (with source code provided). This is a bad idea. It can generally be done, and it’s probably not even too hard (for some uses, anyway). But it’s a bad idea. Here’s why: 1) Applications that don’t know they’re operating in FIPS mode may attempt to use algorithms that are disallowed in FIPS mode. Because the application wasn’t designed for this situation, if the algorithm is attempted through the proper APIs, use of the algorithm will fail, and the application’s error report will be incorrect (assuming it even handles the error coming from OpenSSL, and doesn’t fail much later!). 2) Applications that don’t know they’re operating in FIPS mode may attempt to use algorithms that are disallowed in FIPS mode, but using an API that will actually succeed. This will cause issues for the USER, since the user believes the application is operating properly in FIPS mode, when it just did something that’s disallowed! 3) Applications that don’t know they’re operating in FIPS mode may attempt to use SHA-1 in operations that are disallowed in FIPS mode. OpenSSL will allow most uses of SHA-1 in FIPS mode, relying on the application to only use it appropriately. Again, this can cause problems for the user who thinks the application is operating in FIPS mode, but the application has done things that are disallowed! 4) If POST fails or some other problem is detected, where FIPS mode fails to be enabled, an application that doesn’t know anything about FIPS mode will fail in a manner unexpected by the application. Even if you’ve found a way to notify the user (ha! how you gonna do that not knowing if the application is graphical or not, has access to stderr, syslog, or something else entirely?), the application’s failure may not release resources appropriately, or may cause other problems, especially for the end user who keeps trying it over and over again. :) Someone who controls all the applications on a system, however, that one could deal with all of those issues and more. It’d be expensive, and one would probably be unwilling to give that work away whenever one doesn’t have to. :) I’ll let Steve answer the stuff I snipped. :) snip TOM ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Thu, Jan 15, 2015 at 05:46:22AM -0500, jone...@teksavvy.com wrote: On Tue, 13 Jan 2015 21:33:49 -0500 jone...@teksavvy.com jone...@teksavvy.com wrote: So basically every app that uses libssl will have to be modified to add a FIPS_mode_set() call near the beginning. Is that right ? Is there a way to automatically have the FIPS test executed when an application loads the library, w/o the application being modified ? Is such a way used at all ? This is actually mandated these days. The library should do this in its ELF constructor for instance. On Linux usually triggered by /proc/sys/crypto/fips_enabled containing 1 or the environment variable OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and Redhat, which do not use the container blob). Ciao, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Tue, 13 Jan 2015 21:33:49 -0500 jone...@teksavvy.com jone...@teksavvy.com wrote: So basically every app that uses libssl will have to be modified to add a FIPS_mode_set() call near the beginning. Is that right ? Is there a way to automatically have the FIPS test executed when an application loads the library, w/o the application being modified ? Is such a way used at all ? ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Using FIPS mode and modifying apps
Hello, A system running in FIPS can have several applications using libssl. openvpn and openswan are two. There can be 3rd party web servers. So on. Is there any 'library magic' these days that would prevent modifying each and every application to add a FIPS_mode_set() call and error handling ? I guess there isn't although I'm not risking anything in asking :) So basically every app that uses libssl will have to be modified to add a FIPS_mode_set() call near the beginning. Is that right ? Thanks for any comments and suggestions ! Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
