Please pardon the top-posting - Outlook webmail is annoying...
- What exception is generated (note - line numbers slightly off from stock
6.0.37 source due to debug I've put in)
Severe: Failed to initialize the SSLEngine.
java.lang.Exception: error:2D06C066:FIPS routines:FIPS_mode_set:fips mode
already set
at org.apache.tomcat.jni.SSL.fipsModeSet(Native Method)
at
org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:274)
- Why is openssl in FIPS mode? Because I've configured my RHEL6 box to be in
FIPS mode at boot time, so the SSL libraries "should" pick this up at runtime.
They do (at least they *seem* to be) within my gSOAP based C++ agent processes
that will talk with Tomcat. I used the following procedures to configure the
box for fips mode at boot:
install dracut-fips
disable prelink and undo existing prelink
rebuild initrd using 'dracut -f'
edit /boot/grub/grub.conf and add 'fips=1 boot=<bootpartition>' to kernal
line
reboot
- Regarding the key init - here's where my knowledge of FIPS breaks down. All
I know is that in non-fips mode this key generates, but in fips mode it doesn't
(the others 5 explicit inits in that macro work just fine
- I was going to make the explicit check for fips already enabled in the
AprLifecyleListener spit out a message along the lines of 'FIPS mode already
initialized' and leave it at that, just to acknowledge that *Tomcat* was asking
for fips mode and the system was already there. If this message isn't really
useful then all the TC changes go away, and we put the call to FIPS_mode() as a
precheck in the TCN fipsModeSet() method.
- Regarding key lengths - you got me. I would have thought TCN could query
openSSL for what *it* thought were legal keys lengths and go from there (a-la
the 'openssl ciphers' command), but I also saw an explicit refence in one of
the openssl docs that certain key lengths for handshaking *were* legal, even
though those same ciphers would be illegal otherwise (section 2.6.2 of the
'User Guide - OpenSSL FIPS Object Module v2.0' - though it doesn't say which
key lengths per se).
Stock JSSE cipher uses a DH key that is too short, hence my little diversion
down the APR/Tomcat Native pathway :)
Right now I'm digging through the openssl source (openssl-1.0.0-27.el6.src.rpm)
trying to figure out exactly *when* the /proc/sys/crypto/fips_enabled file is
referenced. I would have thought it should be looked at least once prior to
any of the FIPS/SSL routines returning....
-Rob
________________________________________
From: Christopher Schultz [ch...@christopherschultz.net]
Sent: Thursday, January 16, 2014 4:23 PM
To: Tomcat Developers List
Subject: Re: Tomcat/FIPS mode on HEL6
Robert,
On 1/16/14, 1:59 PM, Robert Sanders wrote:
> I posted this on Monday from my home account, and have some followups
> from my work account:
>
> Recap: On a RHEL6 box with FIPS enabled at boot time Tomcat 6.0.37
> and Tomcat Native Library 1.1.29 will not start if the APR listener
> is configured with 'FIPSMode="on".
>
> There appear to be two places that are causing an abort during
> initialization:
>
> 1) TCN ssl.c in fipsModeSet - the return from FIPS_mode_set() is 0,
> which triggers a exception
What exception is generated -- including the detail message?
I can't seem to find the reference, but I thought that FIPS_mode_set(1)
when already in FIPS mode would not cause an error. It may not actually
return 1 which is easily fixed if that's the problem.
If it /is/ the problem, I'd be curious why OpenSSL is already in FIPS
mode, since Tomcat should be initializing the library and it shouldn't
be in FIPS mode until that happens.
(There also seems to be a bug in tcnative: when calling FIPS_mode_set,
we should expect the return value to be the same as the input value on
success, not always (int)1).
> 2) If I explicitly check for the current mode and skip the call to
> FIPS_mode_set() if already set to one then the code which
> pregenerates the temporary keys fails in 'initialize'.
This seems like a weird state to me... I'd like to hear the explanation.
> Specifically, the call to generate the RSA 512 bit key fails, which
> causes the routine to abort. A coworker here indicated that the 512
> bit RSA key is invalid for FIPS mode.
My understanding is that FIPS mode as implemented has worked in other
environments, and OpenSSL's FIPS implementation has not changed in quite
a while. Why does this work in other environments and not yours?
> My initial fix to this was to have the JNI call in the
> AprLifecycleListener code try and see if FIPS was already enabled
> before calling fipsModeSet so it could log a suitable message. I
> don't know if there is a way for the TCN ssl.c code to return a
> non-error message back to the AprLifecycleListener startup or not.
> This solved issue #1
What would you return if you could?
> For issue #2 I just removed the line in the SSL_TMP_KEYS_INIT macro
> in TCN ssl.c generating the 512 bit RSA key. Might need to put some
> logic there so that in FIPS mode only FIPS legal key lengths are
> generated...
I'd like to know what the "legal key lengths" are in the first place.
Recent FIPS documents suggest that, for instance, 1024-bit keys are also
unacceptable.
I read-through the code in ssl.c for performing that RSA key generation
and none of it makes any sense to me, honestly: the SSL_temp_keys array
is consulted for values, but does not ever appear to have anything put
into it. RSA keys are created but then ignored. DSA temp keys are
actually inserted into that structure, but RSA keys don't seem to
interact with it at all. :(
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
