-----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 Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
