Re: [openstack-dev] [Openstack-operators] FIPS Compliance
On Wed, Nov 7, 2018 at 7:30 AM Doug Hellmann wrote: > > Joshua Cornutt writes: > > > Doug, > > > > I have such a list put together (my various installation documents for > > getting these clouds working in FIPS mode) but it's hardly ready for > > public consumption. I planned on releasing each bit as a code change > > and/or bug ticket and letting the community consume it as it figures > > some of these things out. > > It's likely that the overall migration will go better if we all have the > full context. So I hope you can find some time to publish some of the > information you've compiled to help with that. > > > I agree that some changes may break backwards compatibility (such as > > Glance's image checksumming), but one approach I think could ease the > > transition would be the approach I took for SSH key pair > > fingerprinting (also MD5-based, as is Glance image checksums) found > > here - https://review.openstack.org/#/c/615460/ . This allows > > administrators to choose, hopefully at deployment time, the hashing > > algorithm with the default of being the existing MD5 algorithm. > > That certainly seems like it would provide the most compatibility in the > short term. > > That said, I honestly don't know the best approach for us to take. We're > going to need people who understand the issues around FIPS and the > issues around maintaining backwards-compatibility to work together to > create a recommended approach. Perhaps a few of the folks on this thread > would be interested in forming a team to work on that? > > Doug > I'd be interested in that. Good idea > > Another approach would be to make the projects "FIPS aware" where we > > choose the hashing algorithm based on the system's FIPS-enforcing > > state. An example of doing so is what I'm proposing for Django > > (another FIPS-related patch that was needed for OSP 13) - > > https://github.com/django/django/pull/10605 > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] FIPS Compliance
The downside of this particular approach is that systems that get promoted to "FIPS mode" will get into a sticky situation as the code originally set hashes to use MD5 but then switches to SHA-x after users may have already used MD5 (and thus have that data stored / recalled). The best way really would be make them as configurable options by the user and only baking in decisions for methods that can handle floating between FIPS and non-FIPS modes. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] FIPS Compliance
Doug, I have such a list put together (my various installation documents for getting these clouds working in FIPS mode) but it's hardly ready for public consumption. I planned on releasing each bit as a code change and/or bug ticket and letting the community consume it as it figures some of these things out. I agree that some changes may break backwards compatibility (such as Glance's image checksumming), but one approach I think could ease the transition would be the approach I took for SSH key pair fingerprinting (also MD5-based, as is Glance image checksums) found here - https://review.openstack.org/#/c/615460/ . This allows administrators to choose, hopefully at deployment time, the hashing algorithm with the default of being the existing MD5 algorithm. Another approach would be to make the projects "FIPS aware" where we choose the hashing algorithm based on the system's FIPS-enforcing state. An example of doing so is what I'm proposing for Django (another FIPS-related patch that was needed for OSP 13) - https://github.com/django/django/pull/10605 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FIPS Compliance
Sean, I'm, too, am very interested in this particular discussion and working towards getting OpenStack working out-of-the-box on FIPS systems. I've submitted a few patches (https://review.openstack.org/#/q/owner:%22Joshua+Cornutt%22) recently and plan on going down my laundry list of patches I've made while deploying Red Hat OpenStack 10 (Newton), 13 (Queens), and community master on "FIPS mode" RHEL 7 servers. I've seen a lot of debate in other communities on how to approach the subject ranging from full MD5-to-SHAx transitions to putting in FIPS-aware logic to decide hashes based on the system to just deciding that the hashes aren't used for real security and thus are "mostly OK" by FIPS 140-2 standards (resulting in awkward distro-specific versions of popular crypto libraries with built-in FIPS awareness). Personally, I've been more in favor of a sweeping MD5-to-SHAx transition due to popular crypto libraries (OpenSSL, hashlib, NSS) indiscriminately disabling MD5 hash methods on FIPS mode systems. With SHA-1 collisions already happening, I imagine it will meet the FIPS banhammer in the not-so-distant future which is why I have generally been recommending SHA-256 as an MD5 replacement, despite the larger output size (mostly an issue for fixed-sized database columns). There is definite pressure being put on some entities (commercial as well as government / DoD) to move core systems to FIPS mode and auditors are looking more and more closely at this particular subject and requiring strong justification for not meeting FIPS compliance on systems both at the hardware and software levels. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
