We’ve been working for a few months on making the Chef Client FIPS 140-2 compliant for those that need it for there environments. That work is making it’s way into the general availability Chef Client this quarter. If you don’t know about FIPS 140, it’s government mandate to ensure you’re using approved cryptographic algorithms. It’s a fine idea on the surface, but the implementation is kind of a bureaucratic pit of despair. TLDR; if you aren’t required to have it, you don’t want it.
Some of the work will be of benefit to and affect regular chef-client users over time, some will only matter if you’re running the client with FIPS mode enabled.
Last month we created a new [optional] version of the signing protocol (rfc065) between the client and server (1.3) that uses SHA256 instead of SHA1 for the digital signatures. That has been released in mixlib-authentication 1.4 this month. I believe the next official release of the Chef Server will support that, and then if you wanted to you could set your clients to use 1.3 by setting :authentication_protocol_version in your client.rb. The upcoming FIPS mode will force that setting to 1.3 for compliance reasons. Some later year we’ll probably increase the default from 1.1 to 1.3 for everyone, but that’s far over the horizon.
The big FIPS mode only feature is that when FIPS mode is enabled, you’ll be using the OpenSSL FIPS Object Module / container, which prevents you from using non-approved cryptographic algorithms via OpenSSL (sometimes harshly because a lot of software isn’t written to handle that case and crashes).
Down the road we will likely stop using MD5 to create hashes of files for indexing in the database, and stop using MD5 as a CRC check for files in transit to S3/bookshelf. These aren’t used for cryptographic purposes, but MD5 is a non-approved FIPS algorithm so it scares auditors and auditees when they see it.