FIPS validation and documents
I noticed the OpenSSL FIPS Provider is not listed on the CMVP Modules In Process List. Assuming this is the 3.0 FIPS module that was just released. Nice work on getting to this point. Which platforms is the module being validated on? I haven't seen an official list if that was published somewhere. Are there plans to publish the FIPS documents? When and where do you think we'll see those? Thanks, Zeke Evans Micro Focus
RE: client authentication status
Thanks for the explanation. I figured I was headed down a dead end. This will at least help me figure out how to handle things appropriately. Zeke Evans
client authentication status
Hi, Is there any way to check the status of client authentication sent in a TLS 1.3 handshake after SSL_connect returns? With TLS 1.2 SSL_connect seems to always capture the status and return an error code if it failed but not TLS 1.3. I haven't been able to find a good way to do this after SSL_connect returns. I have to handle blocking and non-blocking sockets so calling SSL_read or SSL_peek isn't an option since those could block. If client authentication happened to fail then calling those methods would work because they will return an error but if it didn't fail then they could block. Thanks, Zeke Evans
RE: PKCS12 APIs with fips 3.0
That works. Thanks! -Original Message- From: openssl-users On Behalf Of Dr Paul Dale Sent: Tuesday, January 26, 2021 6:01 PM You could set the default property query to "?fips=yes". This will prefer FIPS algorithms over any others but will not prevent other algorithms from being fetched. Pauli
RE: PKCS12 APIs with fips 3.0
I understand that PKCS12 cannot be implemented in the fips provider but I'm looking for a suitable workaround, particularly something that is close to the same behavior as 1.0.2 with the fips 2.0 module. In my case, the default provider is loaded but I am calling EVP_set_default_properties(NULL, "fips=yes"). I can wrap calls to the PKCS12 APIs and momentarily allow non-fips algorithms (ie: "fips=no" or "provider=default") but that prevents the PKCS12 implementation from using the crypto implementations in the fips provider. Is there a property string or some other way to allow PKCS12KDF in the default provider as well as the crypto methods in the fips provider? I have tried "provider=default,fips=yes" but that doesn't seem to work. Using the default provider is probably a reasonable workaround for reading in PKCS12 files in order to maintain backwards compatibility. Is there a recommended method going forward that would allow reading and writing to a key store while only using the fips provider? Thanks, Zeke Evans Micro Focus -Original Message- From: openssl-users On Behalf Of Dr Paul Dale Sent: Tuesday, January 26, 2021 5:22 PM To: openssl-users@openssl.org Subject: Re: PKCS12 APIs with fips 3.0 I'm not even sure that NIST can validate the PKCS#12 KDF. If it can't be validated, it doesn't belong in the FIPS provider. Pauli On 26/1/21 10:48 pm, Tomas Mraz wrote: > On Tue, 2021-01-26 at 11:45 +, Matt Caswell wrote: >> >> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote: >>> On 2021-01-25 17:53, Zeke Evans wrote: >>>> Hi, >>>> >>>> >>>> >>>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, >>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips >>>> provider. It looks like that is because they try to load PKCS12KDF >>>> which is not implemented in the fips provider. These were all >>>> working in 1.0.2 with the fips 2.0 module. Will they be supported >>>> in 3.0 with fips? If not, is there a way for applications running >>>> in fips approved mode to support the same functionality and use >>>> existing stores/files that contain PKCS12 objects? >>>> >>>> >>>> >>> This is an even larger issue: Is OpenSSL 3.x so badly designed that >>> the "providers" need to separately implement every standard or >>> non-standard combination of algorithm invocations? >>> >>> In a properly abstracted design PKCS12KDF would be implemented by >>> invoking general EVP functions for underlying algorithms, which >>> would in turn invoke the provider versions of those algorithms. >> >> This is exactly the way it works. The implementation of PKCS12KDF >> fetches the underlying digest algorithm using whatever providers it >> has available. So, for example, if the PKCS12KDF implementation needs >> to use SHA256, then it will fetch an available implementation for it >> - and that implementation may come from the FIPS provider (or any >> other provider). >> >> However, in 3.0, KDFs are themselves fetchable cryptographic >> algorithms implemented by providers. The FIPS module implements a set >> of KDFs - but PKCS12KDF is not one of them. Its only available from >> the default provider. >> >> So, the summary is, while you can set things up so that all your >> crypto, including any digests used by the PKCS12KDF, all come from >> the FIPS provider, there is no getting away from the fact that you >> still need to have the default provider loaded in order to have an >> implementation of the PKCS12KDF itself - which will obviously be >> outside the module boundary. >> >> There aren't any current plans to bring the implementation of >> PKCS12KDF inside the FIPS module. I don't know whether that is >> feasible or not. > > IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS > approved KDF algorithm. Besides that KDF should not IMO be needed for > "modern" PKCS12 files. I need to test that though. >
PKCS12 APIs with fips 3.0
Hi, Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips provider. It looks like that is because they try to load PKCS12KDF which is not implemented in the fips provider. These were all working in 1.0.2 with the fips 2.0 module. Will they be supported in 3.0 with fips? If not, is there a way for applications running in fips approved mode to support the same functionality and use existing stores/files that contain PKCS12 objects? Thanks, Zeke Evans Micro Focus
Re: [openssl-users] [openssl-project] OpenSSL 3.0 and FIPS Update
Can you give any guidance on which platforms will be validated with the OpenSSL FIPS 3.0 module? My recollection is that it will only be a handful of platforms. It would be helpful to have an idea which platforms will and will not be included. Any additional information about how other platforms can be validated would also be helpful. Thanks, Zeke Evans Senior Software Engineer, Micro Focus From: openssl-project on behalf of Matt Caswell Sent: Wednesday, February 13, 2019 4:26 AM To: openssl-annou...@openssl.org; openssl-users@openssl.org; openssl-proj...@openssl.org Subject: [openssl-project] OpenSSL 3.0 and FIPS Update Please see my blog post for an OpenSSL 3.0 and FIPS Update: https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Matt ___ openssl-project mailing list openssl-proj...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS 140-2 key wrapping transition
I am trying to understand how validation #1747 is affected by the key wrapping transition. As far as I can tell, the FIPS module does not contain a key wrapping algorithm per se but only provides approved methods that a key wrapping algorithm could use. Does FIPS 2.0 contain approved methods in order to implement a key wrapping algorithm compliant with SP 800-38f? Is FIPS_evp_des_ede3_cbc not sufficient? If not, why would the absence of that push validation #1747 to the Historical list? I am not seeing a claim the key wrapping is covered in validation #1747 or any code inside the module that implements something that is now deprecated. Is it at all possible to implement a compliant key wrapping method in the FIPS capable code using approved methods? I realize if this was possible it probably would have been done already. I am just hoping to understand the issues surrounding this. Thanks for your help! Zeke Evans Senior Software Engineer Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Salz, Rich via openssl-users Sent: Friday, February 02, 2018 5:26 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] FIPS 140-2 key wrapping transition The OpenSSL FIPS Validation #1747 is affected by the key wrapping transition and will therefore be moved to Historical at some point. As we’ve said, FIPS will be the focus of our next feature release after 1.1.1 (TLS 1.3). -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] FIPS 140-2 key wrapping transition
Hi, NIST recently gave notice of Symmetric Key Wrapping Transition, details are found here https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices. It is not clear to me whether the FIPS 2.0 module is affected by this. I am mostly curious about this part: All validations on the Active Validation List that implement the previously allowed AES or TDEA key wrapping: * Entries will be moved to the Historical List. Can someone verify whether the FIPS 2.0 validation is affected by this? Thanks, Zeke Evans Senior Software Engineer Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] new FIPS module
> As always, if you don't care about FIPS 140 then count yourself lucky and > move on. > > Work on the new FIPS module has so far taken a backseat to higher priority > topics like the 1.1 release and security vulnerabilities, but we should start > to > make some progress soon. I've put together a rough wiki page outlining > some goals for the new FIPS module: > > https://wiki.openssl.org/index.php/FIPS_module_3.0 > > Within the very tight constraints of schedule, resources, and what is > permitted by FIPS 140, we want this FIPS module to be as widely useful as > possible. > > If we've omitted anything of vital importance please speak up. The fixed base address requirement causes problems for large Windows x86 applications and there isn't a great work around. It isn't clear to me if item 2 " Support compilation in various forms" will address this or not. An option to compile the fips module as a dll instead of a static lib would be nice or at least allow the fips capable module to be rebased. Zeke Evans Senior Software Engineer Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] fingerprint mismatch issue with fips build on Win32
Hi, Our win32 applications will sometimes fail to start due to a fingerprint mismatch in the fips module. It appears this is caused by the fixed baseaddr used to verify the checksum. We are building with the /FIXED and /DYNAMICBASE:NO options. The User Guide states: "The standard OpenSSL build with the fips option will use a base address for libeay32.dll of 0xFB0 by default. This value was chosen because it is unlikely to conflict with other dynamically loaded libraries. In the event of a clash with another dynamically loaded library which will trigger runtime relocation of libeay32.dll, the integrity check will fail with the error FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELOCATED A base address conflict can be resolved by shuffling the other DLLs or re-compiling OpenSSL with an alternative base address specified with the --with-baseaddr= option." How is 0xFB0 unlikely to conflict with other DLLs? How would an application select a base address that is less likely to have a conflict? Or, how can an application realistically shuffle the other DLLs? FWIW, the applications load many other DLLs and some are .NET applications. One train of thought is to load the OpenSSL DLL early on, but in some cases that is not practical such as a .NET application. As a side note, the issue appears more frequently when the application is loaded through Visual Studio (not a real world scenario). Thanks, Zeke ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Does CVE-2014-3569 apply without the no-ssl3 build option
Thanks for clarifying. On Tue, Dec 30, 2014 at 5:55 AM, Kurt Roeckx wrote: > On Mon, Dec 29, 2014 at 10:37:49AM -0700, Zeke Evans wrote: >> Is an OpenSSL 1.0.1j build that does not use the no-ssl3 build option >> still vulnerable to CVE-2014-3569? It seems the SSLv3 handshake to a >> no-ssl3 application scenario is just one way to exploit this and that >> the ssl23_get_client_hello function causes this issue for any >> unsupported or unrecognized version. > > The can return NULL in case of no-ssl2 or no-ssl3 when receiving > SSLv2 or SSLv3. But in case of SSLv2 that function isn't called, > it directly sets the method to SSLv2_server_method() in that case > if the previous if block. > > Please note that s->verion can't be set to a unknown value but can > be set to an unsupported value. SSL2_VERSION and SSL3_VERSION are > the only 2 options that are known but can be unsupported. But as > stated above this doesn't affect SSLv2. > > So in summary this only has an effect when build using no-ssl3. > > > Kurt > > ___ > openssl-users mailing list > openssl-users@openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-users ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
[openssl-users] Does CVE-2014-3569 apply without the no-ssl3 build option
Is an OpenSSL 1.0.1j build that does not use the no-ssl3 build option still vulnerable to CVE-2014-3569? It seems the SSLv3 handshake to a no-ssl3 application scenario is just one way to exploit this and that the ssl23_get_client_hello function causes this issue for any unsupported or unrecognized version. Thanks, Zeke ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: bn_mul_mont_fpu multiply-defined error
That resolved the issue. Thanks! On Thu, Jul 4, 2013 at 4:22 AM, Dr. Stephen Henson wrote: > On Wed, Jul 03, 2013, Zeke Evans wrote: > >> I built the FIPS module as specified in the User Guide (only using >> ./config). The 'bn_mul_mont_fpu' multiply-defined error only occurs >> when building the fips capable code when using the 'shared' option (I >> only tested 1.0.1e and 1.0.1c). >> >> I don't think there is anything wrong with the FIPS module because I >> am able to use it to build 1.0.1e with 'fips' but without 'shared' >> being specified and all tests pass successfully. >> > > All symbols in the validated module should being fips_* or FIPS_* to avoid > clashes but that one was overlooked. As a workaround I'd suggest renaming the > symbol in the FIPS capable OpenSSL to something like ossl_bn_mul_mont_fpu. > Make sure OpenSSL compiles *without* the fips option when you do that (to > ensure you're using the correct symbol). > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: bn_mul_mont_fpu multiply-defined error
I built the FIPS module as specified in the User Guide (only using ./config). The 'bn_mul_mont_fpu' multiply-defined error only occurs when building the fips capable code when using the 'shared' option (I only tested 1.0.1e and 1.0.1c). I don't think there is anything wrong with the FIPS module because I am able to use it to build 1.0.1e with 'fips' but without 'shared' being specified and all tests pass successfully. On Wed, Jul 3, 2013 at 4:50 PM, Porter, Andrew wrote: > From the User Guide for the OpenSSL FIPS Object Module v2.0, section 3.2: > > "note the ./config 'shared' option is forbidden by the terms of the > validation when building a FIPS validated module, but the fipscanister.o > object module can be used in a shared library." > > -Original Message- > From: owner-openssl-us...@openssl.org > [mailto:owner-openssl-us...@openssl.org] On Behalf Of Zeke Evans > Sent: Wednesday, July 03, 2013 4:29 PM > To: openssl-users@openssl.org > Subject: bn_mul_mont_fpu multiply-defined error > > I get an error building a fips capable shared object on sparc64. > > ./config fips shared > make depend > make > > ld: fatal: symbol 'bn_mul_mont_fpu' is multiply-defined: > (file /usr/local/ssl/fips-2.0/lib//fipscanister.o type=FUNC; file > libcrypto.a(sparcv9a-mont.o) type=FUNC); > ld: fatal: file processing errors. No output written to libcrypto.so.1.0.0 > make[4]: *** [link_a.solaris] Error 1 > > There are no errors if I build without the shared option. Is that not > supported? > > Thanks, > Zeke > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
bn_mul_mont_fpu multiply-defined error
I get an error building a fips capable shared object on sparc64. ./config fips shared make depend make ld: fatal: symbol 'bn_mul_mont_fpu' is multiply-defined: (file /usr/local/ssl/fips-2.0/lib//fipscanister.o type=FUNC; file libcrypto.a(sparcv9a-mont.o) type=FUNC); ld: fatal: file processing errors. No output written to libcrypto.so.1.0.0 make[4]: *** [link_a.solaris] Error 1 There are no errors if I build without the shared option. Is that not supported? Thanks, Zeke __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
bn_mul_mont_fpu multiply-defined error building sparc64 fips capable shared object
I get an error building a fips capable shared object on sparc64. ./config fips shared make depend make ld: fatal: symbol 'bn_mul_mont_fpu' is multiply-defined: (file /usr/local/ssl/fips-2.0/lib//fipscanister.o type=FUNC; file libcrypto.a(sparcv9a-mont.o) type=FUNC); ld: fatal: file processing errors. No output written to libcrypto.so.1.0.0 make[4]: *** [link_a.solaris] Error 1 There are no errors if I build without the shared option. Is that not supported? Thanks, Zeke __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Building FIPS module on sparc 64bit
Thanks for the clarification and pointing me to the testing docs. One part of your reply I don't understand -- > The Security Policy documents the command as "./config", not "./config no-asm" The build works without no-asm, but I don't understand how the Security Policy does not allow "./config no-asm". I intend to build with just "./config" but want to make sure I understand when no-asm is and is not allowed. Appendix A specifies both. There is a note in the User Guide about the use of no-asm depending on the platform, but I don't see anything that suggests you can't use no-asm with SPARC. On Thu, Feb 14, 2013 at 8:55 AM, Steve Marquess wrote: > On 02/13/2013 06:58 PM, Zeke Evans wrote: >> Hi, >> >> Building the FIPS module on sparc 64-bit is generating a 32-bit >> binary. The following message is in the output: >> >> WARNING! If you wish to build 64-bit library, then you have to >> invoke './Configure solaris64-sparcv9-cc' *manually*. >> >> My understanding is that building with that command is not allowed. >> Another work around is to call >> >> KERNEL_BITS=64 ./config no-asm >> >> Is this permissible? > > Yes, with two caveats: > > 1) The Security Policy documents the command as "./config", not > "./config no-asm". > > 2) For conformity to the Security Policy I would invoke the "./config" > command on a separate line, e.g. > > $ export KERNEL_BITS=64 > $ ./config > > The fact that these commands are functionally equivalent to what you are > doing is irrelevant for compliance purposes; those Security Policy > instructions should be taken literally. Software development "common > sense" does not apply. > > Note the formal testing used this enormously complicated and > sophisticated script to set the environment: > > > http://opensslfoundation.com/testing/validation-2.0/platforms/solaris/setenv-sparc-64.sh > > -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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Building FIPS module on sparc 64bit
Hi, Building the FIPS module on sparc 64-bit is generating a 32-bit binary. The following message is in the output: WARNING! If you wish to build 64-bit library, then you have to invoke './Configure solaris64-sparcv9-cc' *manually*. My understanding is that building with that command is not allowed. Another work around is to call KERNEL_BITS=64 ./config no-asm Is this permissible? Should the config script be using "isainfo -kv" instead of getconf? -bash-3.2$ getconf KERNEL_BITS getconf: Invalid argument (KERNEL_BITS) -bash-3.2$ isainfo -kv 64-bit sparcv9 kernel modules Thanks, Zeke __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
