RE: Tomcat 6.0.x release
Will this include the latest Tomcat Native source as well? -Rob From: Mark Thomas [ma...@apache.org] Sent: Thursday, November 13, 2014 11:07 AM To: Tomcat Developers List Subject: Re: Tomcat 6.0.x release On 13/11/2014 16:01, Andrew Carr wrote: > Mark, > > I previously voted on the severity of this issue in bugzilla. > > You looking for verification of the fix and the vote here? Just trying to > clarify. > > +1 on 56780 fix Thanks. 6.0.x uses RTC (Review-Then-Commit). Every proposed change is listed in the status file (http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/STATUS.txt) and needs at least three +1 votes from committers before it can be included. This patch has votes from 2 (Konstantin and me) and needs 1 more. Remy voted for an earlier broken version but that patch had to change after he voted. Mark > > Andrew > > On Thu, Nov 13, 2014 at 4:29 AM, Mark Thomas wrote: > >> Hi, >> >> We need one more vote for the fix for 56780 in 6.0.x. >> >> Once we have that vote I should be be able to find some time to tag and >> roll the release. I'd like to get that done this week if possible since >> I'm at ApacheCon EU next week. >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [Bug 56027] Unable to use TCN on RHEL6 boxes if box is booted in fips mode
Just double checked - error appears to be on my side. I stood up a pristine CentOS 6.5 box with Tomcat 6.0.41/TCN1.1.30 in FIPS mode and it fails to start. Manually applying the bugfix as suggested in bug 56396 does work. My apologies for flagging this as working earlier in this thread. I think there was some debris from testing that actually made things work when I tried to verify this earlier. -R From: Robert Sanders [rsand...@trustedcs.com] Sent: Wednesday, July 02, 2014 10:42 AM To: Tomcat Developers List Subject: RE: [Bug 56027] Unable to use TCN on RHEL6 boxes if box is booted in fips mode Now I'm confused. When Mladen posted his patch against bug 56396 I'd pulled that code and tested it and it worked. So I thought it would be in TCN 1.1.30. But when I look at TCNative 1.1.30 (included in Tomcat 6.0.41) I don't see that code, and without it my tests should have failed. So it looks like I not only messed up my testing against bug 56396 (pulled wrong code?), but also must have done something wrong when testing 6.0.41 with the included tcn1.1.30 last week. Let me see if I can figure out what I did wrong. -R From: bugzi...@apache.org [bugzi...@apache.org] Sent: Wednesday, July 02, 2014 10:26 AM To: dev@tomcat.apache.org Subject: [Bug 56027] Unable to use TCN on RHEL6 boxes if box is booted in fips mode https://issues.apache.org/bugzilla/show_bug.cgi?id=56027 --- Comment #22 from Konstantin Kolinko --- (In reply to Ben Mason from comment #21) > Is this the key length issue? It is > unclear in this thread whether that was ever fixed. Rob Sanders said he > filed another bug, but it appears it was deleted. Key length issue is bug 56396, should be fixed in TCNative 1.1.31. (r1587896) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [Bug 56027] Unable to use TCN on RHEL6 boxes if box is booted in fips mode
Now I'm confused. When Mladen posted his patch against bug 56396 I'd pulled that code and tested it and it worked. So I thought it would be in TCN 1.1.30. But when I look at TCNative 1.1.30 (included in Tomcat 6.0.41) I don't see that code, and without it my tests should have failed. So it looks like I not only messed up my testing against bug 56396 (pulled wrong code?), but also must have done something wrong when testing 6.0.41 with the included tcn1.1.30 last week. Let me see if I can figure out what I did wrong. -R From: bugzi...@apache.org [bugzi...@apache.org] Sent: Wednesday, July 02, 2014 10:26 AM To: dev@tomcat.apache.org Subject: [Bug 56027] Unable to use TCN on RHEL6 boxes if box is booted in fips mode https://issues.apache.org/bugzilla/show_bug.cgi?id=56027 --- Comment #22 from Konstantin Kolinko --- (In reply to Ben Mason from comment #21) > Is this the key length issue? It is > unclear in this thread whether that was ever fixed. Rob Sanders said he > filed another bug, but it appears it was deleted. Key length issue is bug 56396, should be fixed in TCNative 1.1.31. (r1587896) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [Bug 56027] Unable to use TCN on RHEL6 boxes if box is booted in fips mode
I tested TCN 1_1_30 with Tomcat 6 (which our app uses) and everything appears to work just fine. I haven't updated our install to try working with Tomcat 7. This is on a CentOS 6.5 (yum updated) box with fips mode enabled at boot, and a server.xml similar to yours. Just looking quickly at your log I'm concerned about the 'Failed to initialize the SSLEngine' message near the beginning. As I recall I use to see this if I explictly tried to initialize the SSL Engine twice - which openssl throws an exception on. -R From: bugzi...@apache.org [bugzi...@apache.org] Sent: Wednesday, June 25, 2014 12:56 PM To: dev@tomcat.apache.org Subject: [Bug 56027] Unable to use TCN on RHEL6 boxes if box is booted in fips mode https://issues.apache.org/bugzilla/show_bug.cgi?id=56027 Simon Mijolovic changed: What|Removed |Added Status|RESOLVED|REOPENED Version|1.1.29 |1.1.30 Resolution|FIXED |--- --- Comment #19 from Simon Mijolovic --- Still running into this issue where the APR library won't load when in fips mode using the FIPS validated OpenSSL library. CentOS 6.5 with OpenSSL 1.0.1e-16..el6_5.x86_64, and /boot/grub/grub.conf has fips=1 (prelink disabled, dracut -f, reboot shows "cat /proc/sys/crypto/fips_enabled" = 1) Tomcat 7.0.54 running, and compiled the tcnative APR lib with: ./configure --with-apr=`which apr-1-config` --with-java-home=/usr/java/jdk1.8.0_05 --with-ssl=yes --prefix=/usr/share/apache-tomcat-7.0.54 Setenv.sh: #!/bin/bash umask 0026 LD_LIBRARY_PATH=/usr/share/apache-tomcat-7.0.54/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH Server.xml: Connector.xml: Starting services: service tomcat start Using CATALINA_BASE: /usr/share/apache-tomcat-7.0.54 Using CATALINA_HOME: /usr/share/apache-tomcat-7.0.54 Using CATALINA_TMPDIR: /usr/share/apache-tomcat-7.0.54/temp Using JRE_HOME:/usr/java/jdk1.8.0_05/jre Using CLASSPATH: /usr/share/apache-tomcat-7.0.54/bin/bootstrap.jar:/usr/share/apache-tomcat-7.0.54/bin/tomcat-juli.jar Tomcat started. logs/catalina.2014-06-12.log: Jun 12, 2014 1:30:20 PM org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.30 using APR version 1.3.9. Jun 12, 2014 1:30:20 PM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true ]. Jun 12, 2014 1:30:20 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent SEVERE: Failed to initialize the SSLEngine. org.apache.tomcat.jni.Error: 70023: This function has not been implemented on this platform at org.apache.tomcat.jni.SSL.initialize(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListene r.java:270) at org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListen er.java:124) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.j ava:117) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90 ) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:99) at org.apache.catalina.startup.Catalina.load(Catalina.java:638) at org.apache.catalina.startup.Catalina.load(Catalina.java:663) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:280) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:454) Jun 12, 2014 1:30:20 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-apr-9443"] Jun 12, 2014 1:30:20 PM org.apache.coyote.AbstractProtocol init SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-apr-9443"] java.lang.Exception: Unable to create SSLContext. Check that SSLEngine is enabled in the AprLifecycleListener, the AprLifecycleListener has initialised correctly and that a valid SSLProtocol has been specified at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:503) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:640) at org.apache.coyote.AbstractProtocol.init(
RE: [VOTE] Release Apache Tomcat Native 1.1.30
I'll concur with Chris for release. WRT BZ 56027 there is no regression. The exposure of the fipsModeGet will be useful moving forward to have the main Tomcat code avoid a double call to initialize SSL, but some one with more understanding of the FIPS requirements that I do should look at how TCN is pre-generating keys lengths. -R > The Apache Tomcat Native 1.1.30 is > [X] Stable, go ahead and release > [ ] Broken because of ... - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat Native 1.1.30
Just tested against a CentOS 6 box configured to be in FIPS mode at boot as per RH's directions and TCN will not start, tossing the same error I saw before in catalina.out: Apr 10, 2014 9:01:19 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent SEVERE: Failed to initialize the SSLEngine. java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:269) at org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:108) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:813) at org.apache.catalina.startup.Catalina.load(Catalina.java:538) at org.apache.catalina.startup.Catalina.load(Catalina.java:562) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:261) Commenting out line 77 (where the 512 bit RSA key is generated) allows TCN to start and run normally. I don't understand all of the FIPS requirements, but should execution be allowed to continue if we can generate *any* of the initial keys rather than requiring all of them? The logic of the macros in lines 68 through 82 wind up causing the SSL_TMP_KEYS_INIT(r) call at line 692 to fire if any key init fails, rather than seeing if at least one passes. I did see in the changelog that BZ 56027 is only partially addressed, in that the fipsModeGet() method is now available. -Rob ____ From: Robert Sanders [rsand...@trustedcs.com] Sent: Thursday, April 10, 2014 9:15 AM To: Tomcat Developers List Subject: RE: [VOTE] Release Apache Tomcat Native 1.1.30 Is the TCN portion of BZ 56027 address completely or partially with this release? I see the exposure of the FIPS_mode setting, but it looks like the temporary 512 bit RSA key is still being done in the SSL_TMP_KEYS_INIT macro (line 77). When I hacked my workaround eariier this year I had to make sure I didn't call FIPS_mode_set if it was already set and disable the 512 bit key to get TCN to spin up correctly. -Rob From: Mladen Turk [mt...@apache.org] Sent: Thursday, April 10, 2014 9:01 AM To: dev@tomcat.apache.org Subject: Re: [VOTE] Release Apache Tomcat Native 1.1.30 On 04/10/2014 02:56 PM, Ognjen Blagojevic wrote: > > Tested with Tomcat 8.0.5, Oracle Java 1.7.0_51 on Windows 7 64-bit. > > - Filippo.io [1] reports it is not vulnerable to Heartbleed bug. > > - SSLLabs [2] reports it is not vulnerable to Heartbleed bug. > > - SSLLabs reports that Forward secrecy is enabled when proper cipher suites > (including EECDH/ECDHE) are enabled. > > - Smoke tests of APR, with and without TLS, all passed. > Cool. Thanks -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat Native 1.1.30
Is the TCN portion of BZ 56027 address completely or partially with this release? I see the exposure of the FIPS_mode setting, but it looks like the temporary 512 bit RSA key is still being done in the SSL_TMP_KEYS_INIT macro (line 77). When I hacked my workaround eariier this year I had to make sure I didn't call FIPS_mode_set if it was already set and disable the 512 bit key to get TCN to spin up correctly. -Rob From: Mladen Turk [mt...@apache.org] Sent: Thursday, April 10, 2014 9:01 AM To: dev@tomcat.apache.org Subject: Re: [VOTE] Release Apache Tomcat Native 1.1.30 On 04/10/2014 02:56 PM, Ognjen Blagojevic wrote: > > Tested with Tomcat 8.0.5, Oracle Java 1.7.0_51 on Windows 7 64-bit. > > - Filippo.io [1] reports it is not vulnerable to Heartbleed bug. > > - SSLLabs [2] reports it is not vulnerable to Heartbleed bug. > > - SSLLabs reports that Forward secrecy is enabled when proper cipher suites > (including EECDH/ECDHE) are enabled. > > - Smoke tests of APR, with and without TLS, all passed. > Cool. Thanks -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Time for 8.0.4
Konstantin,
Don't want to be putting words in Chris's mouth, but when I filed 56027 I did
some poking around in the underlying openSSL code (at least on my RHEL6 box).
Calling the openssl FIPS_mode_set() method twice causes an error. I'd proposed
exposing an additional routine to check the current status and quietly skip
calling FIPS_mode_set() if we were already in FIPS mode.
-Rob
From: Konstantin Kolinko [knst.koli...@gmail.com]
Sent: Tuesday, March 18, 2014 4:11 PM
To: Tomcat Developers List
Subject: Re: Time for 8.0.4
2014-03-18 23:46 GMT+04:00 Christopher Schultz :
> Mark,
>
> On 3/17/14, 8:19 AM, Mark Thomas wrote:
>> It has been a while since 8.0.3 and the change log is looking rather
>> long. I've a few things left I want to look at but I expect to be in a
>> position to tag 8.0.4 late today / early tomorrow.
>
> Any objections to adding the fix for
> https://issues.apache.org/bugzilla/show_bug.cgi?id=56027, now that there
> has been a tcnative release?
>
> I needed a tcnative release to include some support code to allow the
> APR listener to allow FIPS mode when OpenSSL had already been
> initialized in FIPS mode before the APR listener tries to enter it.
> (Wow, that sentence is awful. Read the bug for a long-winded explanation).
>
According to tc-native changelog, the new function you are calling
there will be in 1.1.30.
The recent release was of mod_jk, not of tc-native. (BTW, no
announcement article on tomcat.a.o). Thus '-1'.
Regarding the patch:
1) Why in the "on" case you are calling "SSL.fipsModeGet()"? If you
hadn't done that, I think it would work with older library versions.
2) In documentation part: update required version of tc-native in
description of this feature.
3) Update "recommended"/"required" versions in APRLifecycleListener?
4) Code style: position of opening '{'.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Time for 8.0.4
TCN was updated? I still see 1.1.29 (15 October 2013) on the tomcat.apache.org links (both docs and download). or am I missing something (likely). -Rob From: Christopher Schultz [ch...@christopherschultz.net] Sent: Tuesday, March 18, 2014 3:46 PM To: Tomcat Developers List Subject: Re: Time for 8.0.4 Mark, On 3/17/14, 8:19 AM, Mark Thomas wrote: > It has been a while since 8.0.3 and the change log is looking rather > long. I've a few things left I want to look at but I expect to be in a > position to tag 8.0.4 late today / early tomorrow. Any objections to adding the fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=56027, now that there has been a tcnative release? I needed a tcnative release to include some support code to allow the APR listener to allow FIPS mode when OpenSSL had already been initialized in FIPS mode before the APR listener tries to enter it. (Wow, that sentence is awful. Read the bug for a long-winded explanation). Thanks, -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Tomcat/FIPS mode on HEL6
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=' 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 >
RE: Tomcat/FIPS mode on HEL6
Another couple of tidbits: A standalone 'c' program running on my FIPs enabled RHEL6.4 box shows the following behavior: FIPS_mode() -> 0 FIPS_selftest() -> 1 FIPS_mode_set(1) -> 1 FIPS_mode() -> 1 FIPS_selftest() -> 1 FIPS_mode_set(1) -> 0 This last 'double' set is one of the two issues I've encountered with the Tomcat init. I would have expected FIPS_mode() to see if /proc/sys/crypto/fips_enabled was set however. I haven't looked at the openSSL code itself yet, but does anyone know at what point FIPS_mode() will return the true FIPS setting? It obviously doesn't if it is the first thing done in a program even if the system is in fips mode -Rob ____ From: Robert Sanders [rsand...@trustedcs.com] Sent: Thursday, January 16, 2014 1:59 PM To: dev@tomcat.apache.org Subject: Tomcat/FIPS mode on HEL6 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 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'. 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 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 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... -Rob - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat/FIPS mode on HEL6
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 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'. 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 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 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... -Rob
