tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
Date Thu, 13 Jun 2013 21:46:17 GMT
Hash: SHA256


On 6/13/13 5:27 PM, Steve Nickels wrote:
>>> I figured out the problem. The error was due to my system
>>> rebasing the libeay32.dll library from its desired base address
>>> of 0xFB00000. According to OpenSSL documents, this is supposed
>>> to generate a specific error message of 
>> because I wasn't
>>> seeing that, I didn't think that was the problem.
>> Interesting. Do you think it was being swallowed-up somewhere?
>> Like I said, tcnative/FIPS hasn't gotten a huge amount of
>> exposure.
> I think the error message issue might be a problem with OpenSSL 
> itself. As far as I can tell, tcnative is simply parroting back
> the error message that OpenSSL gives it.

It is, but the function we are using says it gets the "first" error
from the error queue. I suppose we could drain the entire error queue
looking for all messages and concatenate them together or something.
We aren't inspecting the entire error queue.

>> Do you think there are ways it could be improved? Better error
>> checking, etc.? I implemented it as simply as I possibly could.
> The biggest problem seems to be that something in Tomcat on Windows
>  is interfering with OpenSSL's normal base address request 
> (0xFB00000). Normally this doesn't matter, but with the FIPS
> build, if the base address of the library is moved from what it
> expects, the result is a fingerprint error when FIPS mode is
> enabled.

This could be a problem on *NIX as well -- any library may be
re-located by the loader for any reason.

> I ran the openssl utility on the same system as Tomcat, and
> Process Explorer shows that its copy of libeay32.dll stays at the
> correct address. Additionally, I tested the FIPS-compatible
> libeay32.dll on a different server with Tomcat, and had the same
> problem. This seems to indicate that the memory address issue is
> specific to Tomcat, not the server.

Or running within a JVM which has a significant amount of native code
that gets loaded first, which may cause the loader to re-locate the
library when it finally gets loaded.

Any interest in trying some Java-based testing using libtcnative?

> I can't tell from Process Explorer why libeay32.dll is being
> rebased (I didn't see any other libraries under tomcat7.exe that
> were obviously taking up the same address space). I think it's
> going to take someone with more experience with both Windows and
> Tomcat than I to figure that one out. I suppose it might be worthy
> of a bug report, at least.

That would be good -- bug reports have more visibility than mailing
list posts, and it's a good place to collect information all in one place.

I'm curious: what base address did you use when you changed it?

> If the fix for the memory rebasing issue ends up being that
> OpenSSL needs to be configured with a different base address, that
> would be good to include in the build documentation for tcnative.
> The file \jni\native\srclib\BUILDING would be a good place for such
> a note. But, if the interfering Tomcat piece were to be found and
> resolved, you wouldn't need it.

I suspect this is an OS-related thing that Tomcat can't really affect.
Note that (other than tcnative and the win32 service-launcher), Tomcat
doesn't have any native code at all, so it can't really affect this
kind of stuff. Tomcat just issues a System.loadLibrary() call and lets
the JVM and OS take over.

>>> With my test application, the original base address was not
>>> being changed by the OS, according to process explorer, which
>>> is why it worked with the original build.
>>> Thanks for your help!
>> No problem. If there were any other gotchas you found when
>> building tcnative/FIPS/win32 could you let us know? Actually,
>> creating a Wiki page is easy to do and you could help others who
>> are trying to do the same thing.
> One minor issue I found when building tcnative on Windows was that
>  the BUILDING file in the \jni\native directory in 
> appears to contain UNIX build 
> instructions. This probably isn't appropriate, since the zip file
> is specific to win32.

That's a good point. Could you log that in Bugzilla as well? There are
(brief) building instructions on
but they should probably also be in the BUILDING file.

> If there's a good place to put a wiki page about this, let me
> know, and I can try to add something.

Really anywhere under would be
great. If I were looking for information about this, I'm not sure
where I'd look first. Perhaps under "Security"?

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message