> On Aug 4, 2016, at 11:00 AM, o haya <oh...@yahoo.com> wrote: > > Hi, > > I've been tasked to look into FIPS 140-2 "compliance" for our systems, > overall, and I know that there's a "FIPS 140-2 module" for OpenSSL, that > needs to be built from source and then integrated into OpenSSL by building > OpenSSL with the FIPS module. > > The User guide goes into how to integrate the resulting OpenSSL(+FIPS module) > with applications, and also has an example of doing that. > > What I was wondering is: Does that mean that EVERY application that we want > to have use the OpenSSL(+FIPS module) would have be (slightly) modified and > then rebuilt from source?
Potentially, yes. Some may already have such modifications. You can also find unofficial patches for some packages to do this, too. Of course, that doesn’t help you with software that uses some other cryptographic software. You’d probably need to make massive changes to them. :) > What about something like Apache? Would we have to modify the Apache source > and rebuild that together with the OpenSSL(+FIPS module)? I believe there are already patches to make apache work with OpenSSL & FIPS. > Finally, what about COTS products, e.g., WebLogic, for which we cannot obtain > the source? You would need to ask your vendors about products that provide FIPS compliance. I really should point out three things, though: 1) FIPS 140 compliance (from any software package) is always less secure than non-FIPS 140 compliant packages. By its nature, the validation process places software several months to years out of date, and no changes are allowed, even to address severe security problems. There are known security problems in at least some of the OpenSSL FIPS modules. 2) FIPS 140 compliance is _not_ about security. It’s about proving that specific algorithms are in use, for purposes of government auditing. Nothing in the compliance tests actually prove that, either. The algorithms must simply be able to produce the correct output for well-known inputs (that includes several runtime tests that also only prove it gives the right output for well-known inputs), and there must exist some sort of “proof” that the module has not been modified from the tested form. There’s nothing in there to prevent FIPS 140 validation of a module that stores all your keys and sends them to someone else, and there’s nothing in there to prevent FIPS 140 validation of a module that contains algorithms that only do the right thing for those well-known inputs. There are even approved algorithms that have been shown to be insecure, even when the software implements the algorithm correctly (see Dual EC DRBG). 3) Unless you’re required by regulation to have FIPS 140 compliance, you should avoid it like the plague it is. It’s less secure, and you’ll never be able to update your software in a timely manner (even if there were no security problems, which is unlikely). Given that you reference COTS instead of GOTS, I suspect you’re not working for a government agency that is required to comply with FIPS 140. Steve Marquess has some excellent posts on his blog about these issues. Here’s one: http://veridicalsystems.com/blog/secure-or-compliant-pick-one/ TOM > Thanks, > Jim > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
