Ohai Chefs! As most of you are already aware, the OpenSSL Heartbleed bug has exposed a giant hole in the security of the Internet over the past few days. Yesterday we released updates to the Chef Server (both Enterprise and Open Source) to address this bug, and we provided instructions on how to properly upgrade an affected server to address the compromised components of your Chef infrastructure. At that time, we incorrectly instructed you that the client keys used to authenticate with the Chef Server were safe:
Chef does authentication and authorization by signing each request, so you don’t have to worry about regenerating your client credentials.
This statement is incorrect, and I’ll tell you about the ways in which your client keys could have been compromised.
By default, the Chef Server generates the client private keys for all of the nodes in your infrastructure when they first register themselves. This private key is not persisted to the Chef Server, but it is transmitted across the network over a secure connection. In this case, that secure connection was provided by HTTPS using the OpenSSL library. Just like any other sensitive information in your Chef infrastructure, it is possible that this data was compromised by the Heartbleed bug. Since the private key is only transferred once, the chances of this information leaking is much lower than other objects, but that chance is still non-zero.
Another scenario in which the Heartbleed bug could potentially expose the client private key is when the Chef Client is connected to compromised server. A compromised server could be the Chef Server or any number of services that the Chef Client connects to, for instance when using the remote_file resource. In this case, a compromised server would be able to send a Heartbleed request back to the client and get access to 64KB of memory from the client. This memory can potentially contain the client’s private key.
Depending on your comfort level with the defense around your Chef Server, you may want to regenerate your client private keys. We’ve published a cookbook that automates the regeneration of client private keys. You can find it on the community site. Alternatively, you can perform this action via the Manage Console (both Enterprise and Open Source) for each individual client.
WARNING: If you use a tool such as chef-vault to encrypt sensitive information out-of-band, and that out-of-band encryption method relies on the public/private keypair of your client, you will need to re-encrypt those new secrets with your tooling of choice.
As we learn more about the Heartbleed bug, we’ll continue to update the community on the status and any additional steps needed to secure your infrastructure.