Created attachment 22917 [details] Add SSLFIPS option. This patch adds FIPS 140-2 support for mod_ssl when used with the newly validated 1.2 OpenSSL FIPS module. A single boolean option SSLFIPS is added. When set FIPS 140-2 mode is enabled. Note that this option by itself does not guarantee FIPS 140-2 compliance, the security policy must also be adhered to. This option is only available if Apache is compiled against an appropriate version of OpenSSL which has been linked to the validated module. Currently only OpenSSL 0.9.8-stable snapshots include the necessary functionality. OpenSSL 0.9.8j will be the first official release. Typically compiling against appropriate headers and linking to an FIPS capable shared library will be required. This option disables generation of temporary keys smaller than 1024 bits because keys smaller than 1024 bits are prohibited in FIPS mode. If compiled against a non-FIPS capable OpenSSL or when the SSLFIPS option is not set it will have no effect.
Steve... when Ben and I each worked on this initially, we came to the conclusion that httpd+mod_ssl should either be compiled to fips-140 binaries, with all of the encumberances that places on the implementation, or compiled to the flexibility that non-fips offers. Do you object if this became a compile-time flag? p.s. I plan to spend a bit of my holiday weekends over this next 6 weeks getting all of these patches into trunk.
(In reply to comment #1) > > Do you object if this became a compile-time flag? > No don't mind at all. There have been a few changes in the latest validation. The PRNG reseeding is no longer necessary. You can also link to FIPS capable shared libraries and it all works OK. Static libraries need modifications to the build procedure. The 1024 bit key restriction is a new requirement though.
(In reply to comment #1) > Steve... > > when Ben and I each worked on this initially, we came to the conclusion that > httpd+mod_ssl should either be compiled to fips-140 binaries, with all of the > encumberances that places on the implementation, or compiled to the flexibility > that non-fips offers. > > Do you object if this became a compile-time flag? > Had a bit of feedback on this. Adding a compile-time flag is OK. However making it always-on is likely to cause problems with distros needing to have two binaries. I'd prefer the configuration option is kept too so the same binary can work as FIPS and non-FIPS. The encumberances in the 1.2 FIPS module are rather less than those in the original. Now an application can just link against shared libraries, which otherwise behave in exactly the same way as OpenSSL 0.9.8. In 1.0 and 1.1 shared libraries were not supported and you had to use a special static only link procedure.
After further study, a run time flag made sense. Committed to trunk, proposed for backport, one issue remains; I'd further modified this patch to indicate when fips mode is or is not in operation, some people have complained about the volume of this log message. I'm considering making this loglevel Info, but suppress the log message when the user explicitly configures SSLFIPS off. Does this make sense?
Apparently this SSLFIPS directive has been added in 2.3.6, 8 years ago, so closing.