search

microsoft / go

The Microsoft build of the Go toolset
BSD 3-Clause "New" or "Revised" License
267 stars 26 forks source link

OpenSSL version 1.1.1 is not listed under OpenSSL Library's FIPS compliant library list #1283

Open andrew-enquanta opened 1 month ago

andrew-enquanta commented 1 month ago

I am trying to utilize Microsoft Go Bullseye container (mcr.microsoft.com/oss/go/microsoft/golang:1.22-bullseye) to use OpenSSL FIPS compliant shared libs to replace stdlib Go crypto as documented here.

However, I am having a hard time reconciling my understanding of OpenSSL's certification windows, which basically states we have to use OpenSSL versions 3.0.0, 3.0.8, or 3.0.9 if we want to be using a FIPS validated OpenSSL.

However, the OpenSSL version in the latest Microsoft Go containers are using version 1.1.1w. Looking at the main README for go-crypto-openssl, it states:

The openssl package has support for multiple OpenSSL versions, namely 1.0.2, 1.1.0, 1.1.1 and 3.0.2.

None of these versions are listed as FIPS validated on OpenSSL's side.

My questions are 2 fold:

  1. What is the difference in what the microsoft/go says is "FIPS" mode vs what OpenSSL says is "FIPS" validated in terms of OpenSSL versions
  2. If we need to be using OpenSSL 3.0.9 as listed in OpenSSL FIPS validated versions list, how could we accomplish that in mcr.microsoft.com/oss/go/microsoft/golang:1.22-bullseye? (i.e. could we just source install https://www.openssl.org/source/openssl-3.0.9.tar.gz and expect the Microsoft go compiler to work?)

Thank you

dagood commented 1 month ago

Looking at the main README for go-crypto-openssl, it states: [...] 3.0.2

In 1.21, we migrated to use golang-fips/openssl, which says 3.x. This section of the FIPS readme mentions the migration: fips#microsoft-go-fork-fips-compliance. (But I think documenting this in the old repo itself is something we should do.)

However, the OpenSSL version in the latest Microsoft Go containers are using version 1.1.1w.

We recommend only using that container to build apps, not to run them. (Use a multi-stage build.) Using the OpenSSL binaries in that container image for crypto would never have been FIPS compliant--it's just the ordinary Debian build of OpenSSL. I don't have a good reference for building OpenSSL 3.x yourself and making sure it's set up correctly in your own image.

The OpenSSL version present when building a Go app with our toolset doesn't affect the OpenSSL versions it can use at runtime, so the important bit is to carefully choose how your app is deployed.

(From https://openssl-library.org/source/ ) All older versions (including 1.1.1, 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used.

This is OpenSSL's declaration of support, but my understanding is that others might support these builds for longer. As far as I know, you would need to ask whoever's providing your OpenSSL build for more information on that.

  1. What is the difference in what the microsoft/go says is "FIPS" mode vs what OpenSSL says is "FIPS" validated in terms of OpenSSL versions

FIPS mode is simply a state of the app. In this mode, OpenSSL will change some behaviors, and we change some behaviors in the Go TLS stack. It doesn't imply that the app is FIPS compliant or FIPS certified.

FIPS certification is a property of a specific OpenSSL build. We don't distribute these ourselves. Some related links:

That said, we do publish images on MAR based on Azure Linux (Mariner), like mcr.microsoft.com/oss/go/microsoft/golang:1.22-cbl-mariner2.0. Check out https://github.com/microsoft/go-images for more info about the spread of tags we produce for builder images.

Sorry that this is a lot to piece together and the end-to-end isn't all that clear. FIPS compliance is a very impactful thing to claim an app has, so most of all I want to avoid a false impression that using our toolset is (currently) making things easy. 😅 It's just one piece of a larger picture.