> That shouldn't be happening at all. The translation of OpenSSL calls to
the
> FIPS_* form should only occur in the FIPS module itself, the FIPS capable
> OpenSSL should have the same functionality as normal but it will call the
> FIPS_* functions when necessary.
>
Thanks for the heads up. I sort of thought this was the case, the
FIPS_digestinit translation was just a GUESS as to what might be happening
since I couldn't find anything else to explain it yet.
> I'm not sure how that could happen unless you're somehow pulling in the
name
> translation from the module by including the private headers and setting
> defines.
>
After further investigation, the FIPS private headers (for instance,
fipssyms.h) are definitely being installed when I do "make install" in the
openssl-fips-2.0.1 directory. Then those headers are being used by my
openssl build, likely due to the openssl FIPS installation directory being
included in the include path when openssl compiles. I thought only the
following would have been installed by openssh-FIPS (and thus visible when
building openssl later): fipsld, fips_standalone_sha1, fips_premain.c,
fips_premain.c.sha1, fipscanister.o, and fipscanister.o.sha1. It turns out
that many fips-private headers (most importantly fipssyms.h which was
included by the FIPS version of crypto.h) are also installed, which is bad
because then openssl library ends up using the redefined FIPS_digestinit
version of EVP_DigestInit(), which doesn't do the initialization.
I removed all of those headers that were installed with openssl-FIPS "make
install", so that openssl wouldn't find them. I eventually came to the
conclusion that the only headers that are necessary are fips.h and
fips_rand.h. The rest don't need to be "installed" in order for openssl to
build, so I'm not sure why they are installed -- especially since use of
them is detrimental to the functionality (or can be, at least in some
cases). The Makefiles all have a variable called EXHEADER and I'm thinking
the only ones that should be installed are those that aren't included in
the openssl 1.0.1c codebase -- namely fips.h and fips_rand.h. But, to each
their own, there must be a reason I'm not aware of that these others are
being installed.
After rebuilding openssl with only those 2 necessary headers present, I get
different errors in openssh -- no seg faults, but no operation either.
#:~# ssh blaander@192.168.178.100
FIPS mode initialized
aes_misc.c(73): OpenSSL internal error, assertion failed: Low level
API call to cipher AES forbidden in FIPS mode!
Aborted
Looks like this was added between March 12 and March 14 if I read the
CHANGES file in openssl correctly. I'm not sure how to solve that one yet.
I'm guessing someone has a patch that will use the EVP* functionality in
openssh (I got a similar patch for the RSA bits and pieces in openssh a
couple years back) rather than the AES functionality directly. Otherwise
I'm trying to figure it out myself. My php installation is still failing
too, and I'll have to figure that out after getting openssh working again.
It could easily be something similar -- someone using an older low-level
API that's been deprecated from external use/visibility in the 2.0 FIPS
version.
Thanks for the help!
Brian Aanderud
"Dr. Stephen
Henson"
<st...@openssl.or To
g> openssl-users@openssl.org
Sent by: cc
owner-openssl-use
r...@openssl.org Subject
Re: openssl FIPS 2.0 - EVP_MD_CTX
initialization
09/25/2012 04:04
PM
Please respond to
openssl-users@ope
nssl.org
On Tue, Sep 25, 2012, blaan...@rockwellcollins.com wrote:
> I've been using openssl-fips for a couple of years. I'm looking to
> upgrade to 2.0 because of the slow (~10 seconds) integrity check on my
> platforms when using version 1.2 when I call "FIPS_mode_set()".
>
> I've got the FIPS canister built, and I've got the openssl 1.0.1c
> libraries all compiled, and all of my apps are now linking just fine.
> Unfortunately there are some runtime issues I'm seeing, seemingly related
> to the EVP_MC_CTX initialization (or lack thereof) prior to calling
> EVP_DigestInit. The man page says that EVP_DigestInit will initialize
the
> input EVP_MD_CTX structure. In the openssl source code that is indeed
the
> case -- EVP_DigestInit immediately calls "EVP_MD_CTX_init" and everything
> is happy.
>
> However, when I'm using the new 2.0 openssl FIPS module, it seems to me
> like it doesn't do a similar initialization -- it's probably calling
> FIPS_digestinit in the background due to the re-definition of
> EVP_DigestInit to FIPS_digestinit in openssl/fipssyms.h or something.
Most
> apps (for instance, openssh) depend on this CTX initialization, and
> without it they tend to seg fault randomly on me. The code in the apps
> will often do something like this -- creating a CTX structure on the
stack
> and using it immediately:
>
> EVP_MD_CTX md;
> EVP_DigestInit(&md, kex->evp_md);
>
> Again, this works fine with the non-FIPS version of openssl, and even
> worked fine in older FIPS openssl (version 1.2). However, now I get seg
> faults.
>
> I put together a patch for openssh that initializes every EVP_MD_CTX
right
> after creation (using the EVP_MD_CTX_init function), and now openssh
works
> just great! All of my seg faults in openssh have gone away. However,
> I've got a pile of other apps (python, php, net-snmmp, etc) which are
also
> skipping the call to "EVP_MD_CTX_init". I don't think it's appropriate
> (or maintainable) for me to patch every single app that ever uses an
> EVP_MD_CTX. What have other users been doing to solve this problem?
>
> And finally, I don't know if this question is more well suited for the
> -dev or the -users mailing list, so I put it in -users and expect that it
> can be copied to -dev if needed.
>
That shouldn't be happening at all. The translation of OpenSSL calls to the
FIPS_* form should only occur in the FIPS module itself, the FIPS capable
OpenSSL should have the same functionality as normal but it will call the
FIPS_* functions when necessary.
I'm not sure how that could happen unless you're somehow pulling in the
name
translation from the module by including the private headers and setting
defines.
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 List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
