Re: openssl-0.9.8n and openssl-fips-1.2 ERR_peek_last_error failure
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Dr. Stephen Henson wrote on 04/08/2010 08:16 PM: On Thu, Apr 08, 2010, Gatewood (Woody) Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Setup: Built openssl-fips-1.2 per the Security Policy. Built openssl-0.9.8n with the fips option Notes: Successfully built FIPS-ified version of wget, curl/libcurl, libssh2 and mod_ssl. Successfully means the work as advertised within the restrictions placed on the application by calling FIPS_mode_set(1). All applications are dynamically linked against libcrypto.so.0.9.8 libssl.so.0.9.8 using CC=fipsld FIPSLD_CC=gcc. Issue: I am seeing a failure of ERR_peek_last_error() which is a pass through call to get_error_values() when linking openvpn via fipsld. Specific case in point is OpenVPN-2.1.1. When called with a certificate file, OpenVPN calls SSL_CTX_use_certificate_chain_file() SSL_CTX_use_certificate_chain_file() builds the certificate chains via calls to PEM_read_bio_X509_AUX() which loads one cert in a file at a time on a file as called in a a loop. When called and no further certificates remain, then PEM_read_bio_X509_AUX() bails setting PEM_R_NO_START_LINE int he error stack. SSL_CTX_use_certificate_chain_file() then calls ERR_peek_last_error() to pop the error stack and so long as the error is the expected PEM_R_NO_START_LINE is set, returns clean to the calling application. For whatever reason in the case of openvpn, ERR_peek_last_error() returns 0 instead of PEM_R_NO_START_LINE (151441516 in my build read as an integer) causing SSL_CTX_use_certificate_chain_file() to return a 0 (failure). Now in the case of failure, within the openvpn code I can add a call to ERR_print_errors_fp(stderr); and see the errors that ERR_peek_last_error() failed to pop. Some debug output... The err set the return value of ERR_peek_last_error(). end called has the ret value Broke (debug output): wdy: SSL_CTX_use_certificate_chain_file checking errors wdy: SSL_CTX_use_certificate_chain_file err set (0) wdy: SSL_CTX_use_certificate_chain_file found real errors? (ret 1) wdy: SSL_CTX_use_certificate_chain_file end called (0) 8500:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:652:Expecting: CERTIFICATE Working (debug output): wdy: SSL_CTX_use_certificate_chain_file checking errors wdy: SSL_CTX_use_certificate_chain_file err set (151441516) wdy: SSL_CTX_use_certificate_chain_file clear error called wdy: SSL_CTX_use_certificate_chain_file end called (1) Now here is the 'real' humor. If I statically link in openvpn libssl.a and libcrypto.a then the function works. The failure only occurs when using/linkng shared objects. That function fails if fipsld is used to link the application even if I do *not* patch/alter the openvpn source code to call FIPS_mode_set(1) and fix a hard coded md5 call. Thoughts? I think I have all the relevant data present. It could be related to the FIPS error code callbacks. Try adding a call to OPENSSL_init() in the application before anything else. Steve. No difference. Added that call as the first thing in main() right before where I would call FIPS_mode_set. Playing around with nm on my resulting fipsld linked openvpn binary, I noticed: 08062f90 T ERR_peek_last_error - globally defined (external) 08062d20 t get_error_values - locally defined Could the 'local' definition be why static linking works but not dynamic? The definition of get_error_values is declared static and thus expected to be local. Having it defined in the binary as a local would prevent a call out to the (.so) library? Thanks, Woody - -- - --- Gatewood Green Sr. Software Engineer/Network Admin Email: wo...@nitrosecurity.com http://www.nitrosecurity.com/ NitroSecurity - --- Imagine, if you will, a world in which there are no hypothetical situations... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ iEYEAREDAAYFAku/WA4ACgkQHnsUla8nzK1aoQCfbiam666qQywRSnOFUlvIzfRO 7H0AoMvwmEkxHc/se3d2rrKnWDPhm+g6 =55I9 -END PGP SIGNATURE- This e-mail message and any attachments contain information that is confidential and may be privileged. If the reader of this e-mail is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to this message or by sending an email to postmas...@nitrosecurity.com, and destroy all copies of this message and any attachments without reading or disclosing them. Thank you
openssl-0.9.8n and openssl-fips-1.2 ERR_peek_last_error failure
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Setup: Built openssl-fips-1.2 per the Security Policy. Built openssl-0.9.8n with the fips option Notes: Successfully built FIPS-ified version of wget, curl/libcurl, libssh2 and mod_ssl. Successfully means the work as advertised within the restrictions placed on the application by calling FIPS_mode_set(1). All applications are dynamically linked against libcrypto.so.0.9.8 libssl.so.0.9.8 using CC=fipsld FIPSLD_CC=gcc. Issue: I am seeing a failure of ERR_peek_last_error() which is a pass through call to get_error_values() when linking openvpn via fipsld. Specific case in point is OpenVPN-2.1.1. When called with a certificate file, OpenVPN calls SSL_CTX_use_certificate_chain_file() SSL_CTX_use_certificate_chain_file() builds the certificate chains via calls to PEM_read_bio_X509_AUX() which loads one cert in a file at a time on a file as called in a a loop. When called and no further certificates remain, then PEM_read_bio_X509_AUX() bails setting PEM_R_NO_START_LINE int he error stack. SSL_CTX_use_certificate_chain_file() then calls ERR_peek_last_error() to pop the error stack and so long as the error is the expected PEM_R_NO_START_LINE is set, returns clean to the calling application. For whatever reason in the case of openvpn, ERR_peek_last_error() returns 0 instead of PEM_R_NO_START_LINE (151441516 in my build read as an integer) causing SSL_CTX_use_certificate_chain_file() to return a 0 (failure). Now in the case of failure, within the openvpn code I can add a call to ERR_print_errors_fp(stderr); and see the errors that ERR_peek_last_error() failed to pop. Some debug output... The err set the return value of ERR_peek_last_error(). end called has the ret value Broke (debug output): wdy: SSL_CTX_use_certificate_chain_file checking errors wdy: SSL_CTX_use_certificate_chain_file err set (0) wdy: SSL_CTX_use_certificate_chain_file found real errors? (ret 1) wdy: SSL_CTX_use_certificate_chain_file end called (0) 8500:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:652:Expecting: CERTIFICATE Working (debug output): wdy: SSL_CTX_use_certificate_chain_file checking errors wdy: SSL_CTX_use_certificate_chain_file err set (151441516) wdy: SSL_CTX_use_certificate_chain_file clear error called wdy: SSL_CTX_use_certificate_chain_file end called (1) Now here is the 'real' humor. If I statically link in openvpn libssl.a and libcrypto.a then the function works. The failure only occurs when using/linkng shared objects. That function fails if fipsld is used to link the application even if I do *not* patch/alter the openvpn source code to call FIPS_mode_set(1) and fix a hard coded md5 call. Thoughts? I think I have all the relevant data present. Thanks, Woody - -- - --- Gatewood Green Sr. Software Engineer/Network Admin Email: wo...@nitrosecurity.com http://www.nitrosecurity.com/ NitroSecurity - --- Imagine, if you will, a world in which there are no hypothetical situations... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ iEYEAREDAAYFAku+b5EACgkQHnsUla8nzK1NwwCfZo0nSh+isuoqwXuekx615Ttj IqkAoN6QynZ6DI6ADjq8HFB1XrNZgiHm =rieQ -END PGP SIGNATURE- This e-mail message and any attachments contain information that is confidential and may be privileged. If the reader of this e-mail is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to this message or by sending an email to postmas...@nitrosecurity.com, and destroy all copies of this message and any attachments without reading or disclosing them. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 and FIPS
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 William A. Rowe Jr. wrote on 03/31/2010 01:20 AM: On 3/30/2010 10:58 AM, Gatewood (Woody) Green wrote: I assume the 2010 limit on new validations is the impending finalization of 140-3. What you are thinking of won't be designated 140-3, it's not sequential, there is such a FIPS level already. Probably FIPS-{new}-2 or FIPS-140-2 2010 or something like that. FIPS 140-3 implies a level of physical validation that an open source project isn't able to consider validating to. If you were to bundle OpenSSL-FIPS into a sealed card, and add the appropriate cert/key mgmt, then you could consider applying for FIPS 140-3 validation for such a physical device. Actually, no 140-3 will be successor to 140-2 which is successor to 140-1. The hyphenated number is a release version. You are trying to talk about FIPS 140-2, Level 3 certification in your example. (bottom of page two in the gov't 140-2 PDF; see link below) The levels are *within* the particular 140-x standard. Case in point, the original draft of 140-3 contained five levels but has since been reduced back to four as is in the 140-2 version. Second example, we have 140-2, Level 2 certification on a subset of our products (version, model and product specific). A reading of the gov't's own file titled fips1402.pdf contains data on all four levels of 140-2 certification. Note the phrasing used in the second paragraph and the security levels starting at the bottom of page one in: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf Backed by the wording The Revised Draft FIPS 140-3 is the second public draft of NIST’s proposed revision of FIPS 140-2. on: http://csrc.nist.gov/publications/PubsDrafts.html And finally, 140-2 certifications issued continue to be valid even after the release of 140-3, but *new* certifications will be required to meet the 140-3 stricter standard. My original question was centered around the idea of whether the 2010 limit Steve M. mentioned was due to the upcoming release of 140-3, a possible update to 140-2 prior to the finalization and release of 140-3 or if he thought the openssl-fips-1.2 certificate might be revoked (as has happened once before with 1.1.2 if I remember correctly). Thanks, Woody - -- - --- Gatewood Green Sr. Software Engineer/Network Admin Email: wo...@nitrosecurity.com http://www.nitrosecurity.com/ NitroSecurity - --- Imagine, if you will, a world in which there are no hypothetical situations... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ iEYEAREDAAYFAkuzvL8ACgkQHnsUla8nzK07GwCfVwX7jVP9T2nPtHzawKHdAVaZ EdIAnioJrMbH7hIpFW2g8emBOTpobgbu =eTij -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 and FIPS
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Given the response... Is there intention that the 0.9.8 branch be maintained past the 'n' patch release for any future discovered security issues either in openssl-0.9.8 code or SSL/TLS protocols as implemented on 0.9.8? I assume the 2010 limit on new validations is the impending finalization of 140-3. As a foot note, having obtained certification previously on a subset of our products, I understand and well appreciate the cost and headache factors involved. Thanks, Woody Steve Marquess wrote on 03/29/2010 06:47 PM: Gatewood (Woody) Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I noticed in trying to build OpenSSL 1.0.0 that Configure no longer accepts the fips and --with-fipslibdir= arguments (as does all 0.9.8 version since j for building in conjunction and with inclusion of openssl-fips-1.2). Are we awaiting another certification pass of an updated canister beyond openssl-fips-1.2? Yes. Is there something significant in the 1.0.0 that fundamentally changes the API? Or is this more of a case of dual branch development and the changes make since 0.9.8j just did not get merged into the 0.9.9/1.0.0 branch? Yes, 1.0.0 is sufficiently different that the existing OpenSSL FIPS Object Module isn't compatible. We'd like to implement the FIPS module functionality into 1.0.0 but just as for the past validations we're pretty much stuck until and if sponsor(s) step forward to fund that effort. In addition to the substantial amount of coding work the test lab fees are far beyond our means without such financial backing. Note also that the rules for FIPS 140-2 validations are changing and even the original 0.9.8 compatible validated module won't be suitable as the basis for new validations beyond 2010. -Steve M. - -- - --- Gatewood Green Sr. Software Engineer/Network Admin Email: wo...@nitrosecurity.com http://www.nitrosecurity.com/ NitroSecurity - --- Imagine, if you will, a world in which there are no hypothetical situations... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ iEYEAREDAAYFAkuyH5wACgkQHnsUla8nzK0DOwCg5NsERo2vk9aAJddKUM4N0T0u cO0AmwYy29BVJ2Um0TTTw6+7/Wy67d2c =12pp -END PGP SIGNATURE- This e-mail message and any attachments contain information that is confidential and may be privileged. If the reader of this e-mail is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to this message or by sending an email to postmas...@nitrosecurity.com, and destroy all copies of this message and any attachments without reading or disclosing them. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL 1.0.0 and FIPS
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I noticed in trying to build OpenSSL 1.0.0 that Configure no longer accepts the fips and --with-fipslibdir= arguments (as does all 0.9.8 version since j for building in conjunction and with inclusion of openssl-fips-1.2). Are we awaiting another certification pass of an updated canister beyond openssl-fips-1.2? Is there something significant in the 1.0.0 that fundamentally changes the API? Or is this more of a case of dual branch development and the changes make since 0.9.8j just did not get merged into the 0.9.9/1.0.0 branch? Thanks, Woody - -- - --- Gatewood Green Sr. Software Engineer/Network Admin Email: wo...@nitrosecurity.com http://www.nitrosecurity.com/ NitroSecurity - --- Imagine, if you will, a world in which there are no hypothetical situations... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ iEYEAREDAAYFAkuw54wACgkQHnsUla8nzK1vJwCfcT6QMTPdfzgrq2gSMpQ9gvGZ NpgAoKoEobL2RkBU4VQSBqXMiJgBZO2W =LX7X -END PGP SIGNATURE- This e-mail message and any attachments contain information that is confidential and may be privileged. If the reader of this e-mail is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to this message or by sending an email to postmas...@nitrosecurity.com, and destroy all copies of this message and any attachments without reading or disclosing them. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org