What version of Go are you using (go version)?
$ go version go version go1.21.0 darwin/arm64
Does this issue reproduce with the latest release?
Yes
What did you do?
When in FIPS-mode, BoringCrypto does not support recently permitted protocols/algorithms.
What did you expect to see?
Support for TLS v1.3 (permitted by NIST SP 800-52 Rev. 2), including cipher suites TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. See also GSA IT Security Procedural Guide: SSL/TLS Implementation CIO-IT Security-14-69. Note that TLS 1.3 support is required starting January 1, 2024.
Support for Ed25519 signature algorithm (permitted by FIPS 186-5).
FIPS 140-3 made some changes that permitted these new protocols/algorithms.
Note that BoringSSL fips-20220613 branch already supports TLS 1.3 and some other improvements by way of SSL_CTX_set_compliance_policy(ssl_compliance_policy_fips_202205). This helps bring BoringCrypto into alignment from the TLS perspective.
What did you see instead?
Only TLS v1.2 supported. No support for TLS v1.3.
No support for Ed25519 as a signature algorithm.
Comment From: gopherbot
Change https://go.dev/cl/524355 mentions this issue: crypto/tls: support TLS 1.3 and Ed25519 signature algorithm in FIPS-mode
Comment From: ianlancetaylor
CC @golang/security
Comment From: dagood
Note that TLS 1.3 support is required starting January 1, 2024.
It sounds like this change is needed in ~~1.21 and 1.22~~ 1.20 and 1.21 because those versions will both still be in support by then, is that correct?
(Edit: Whoops, off by one.)
Comment From: reedloden
Note that TLS 1.3 support is required starting January 1, 2024.
It sounds like this change is needed in 1.20 and 1.21 because those versions will both still be in support by then, is that correct?
As I understand Go's release policy and release cadence, then yes. I had originally included multiple changes in my PR to address the recent FIPS / NIST improvements, but I re-scoped it solely to address the TLS v1.3 support to bring it inline with what BoringSSL already supports and due to the impending deadline. I'll open up additional PRs for other things, but it's possible some of those changes might need re-certification by NIST as part of the move to FIPS 140-3.
Comment From: FiloSottile
The latest BoringCrypto validation, both according to the docs and to a CMVP search is certificate #4407. Its security policy specifies 853ca1ea1168dff08011e5d42d94609cc0ca2e27 as the version, which is fips-20210429.
The Approved Algorithms don't list Ed25519 (which I don't think would have been possible, since this is a FIPS 140-2 certificate). The security policy mentions TLS 1.2 in various places, but not TLS 1.3. ssl_compliance_policy_fips_202205 was added after fips-20210429 was tagged, too.
I'm afraid that we can't enable these algorithms with the current BoringCrypto module version.
The Modules In Process List has a BoringCrypto FIPS 140-3 validation In Review, for what I presume might be fips-20220613. In the past, we have upgraded to a new version of the module while it was In Review, but I can't make that call myself.
@agl, is it ok to switch to fips-20220613? What algorithms are allowed in its policy?
Comment From: reedloden
@FiloSottile To be clear, this is an overarching issue covering the fact that FIPS 140-3 and other NIST standards have changed what's permitted (including Ed25519 as a new approved algorithm). Definitely understand that a validated module is required, but just wanted a tracking issue, as I didn't see anything similar. Great to see that BoringCrypto is undergoing FIPS 140-3 validation. Hopefully, that can be completed soon, and then we can way more easily update Go accordingly.
Separately, #62373 is specifically around enabling TLS 1.3 using the existing fips-20210429 certified module version. The question is whether TLS 1.3 can be used under that version (especially as the security policy doesn't mention TLS 1.2 at all), or if we need to wait for fips-20220613 (or some other BoringSSL FIPS tag).
Comment From: FiloSottile
Discussed this offline with @agl. My understanding is that on the Go side we have three imperfect options:
- wait for
fips-20220613, then enable TLS 1.3, missing the NIST SP 800-52 Rev. 2 deadline - upgrade to
fips-20220613while the module is in review - enable TLS 1.3 with
fips-20210429under the argument that the validated KDF hasn't changed
We have precedent for upgrading to an In Review module, and most consumers I have heard from are comfortable with that, so I'm picking (2). I'll open freeze exception and backport issues next week.
Comment From: reedloden
Appreciate you following-up on this. (2) does seem like the best of the non-great options.
Just to be clear, has it been confirmed that the fips-20220613 tag is what is under review for FIPS 140-3 and not the separate fips-20230428 branch?
Comment From: FiloSottile
I understand that fips-20220613 will be the one we'll hopefully get a certificate for the soonest.
Comment From: reedloden
We have precedent for upgrading to an In Review module, and most consumers I have heard from are comfortable with that, so I'm picking (2). I'll open freeze exception and backport issues next week.
Did the freeze exception and backport issues get filed?
Comment From: gopherbot
Change https://go.dev/cl/549695 mentions this issue: crypto/internal/boring: upgrade module to fips-20220613
Comment From: gopherbot
Change https://go.dev/cl/549975 mentions this issue: crypto/tls: align FIPS-only mode with BoringSSL policy
Comment From: gopherbot
Change https://go.dev/cl/553856 mentions this issue: [release-branch.go1.21] crypto/tls: align FIPS-only mode with BoringSSL policy
Comment From: gopherbot
Change https://go.dev/cl/553855 mentions this issue: [release-branch.go1.21] crypto/internal/boring: upgrade module to fips-20220613
Comment From: gopherbot
Change https://go.dev/cl/553875 mentions this issue: [release-branch.go1.20] crypto/internal/boring: upgrade module to fips-20220613
Comment From: gopherbot
Change https://go.dev/cl/553876 mentions this issue: [release-branch.go1.20] crypto/tls: align FIPS-only mode with BoringSSL policy
Comment From: leungster
I tried pulling in this change in go 1.21.6 and it appears P521 support was dropped with GOEXPERIMENT=boringcrypto and import _ crypto/tls/fipsonly.
It looks like it was dropped intentionally from boringAllowCert. Is that expected?
Comment From: rolandshoemaker
I tried pulling in this change in go 1.21.6 and it appears
P521support was dropped withGOEXPERIMENT=boringcryptoandimport _ crypto/tls/fipsonly.It looks like it was dropped intentionally from boringAllowCert. Is that expected?
Yes, this brings us in alignment with BoringSSL which only permits P-256 and P-384
Comment From: leungster
Thanks for the info. Unfortunately this breaks some of our existing certs in the field and will require a rotation.
Comment From: dio
@FiloSottile sorry, could you help to elaborate on why we didn't go with the currently validated fips-20210429 for enabling TLS1.3? Thank you!
Comment From: FiloSottile
@FiloSottile sorry, could you help to elaborate on why we didn't go with the currently validated
fips-20210429for enabling TLS1.3? Thank you!
See https://github.com/golang/go/issues/62372#issuecomment-1821413387 and https://github.com/golang/go/issues/62372#issuecomment-1827476258. The fips-20210429 Security Policy does not cover the TLS 1.3 KDF.
Some auditors might accept an argument that that's ok, just like some auditors might accept In Review modules. I can't advise on what is necessary for your specific compliance goals.
Comment From: Lekensteyn
I tried pulling in this change in go 1.21.6 and it appears
P521support was dropped withGOEXPERIMENT=boringcryptoandimport _ crypto/tls/fipsonly. It looks like it was dropped intentionally from boringAllowCert. Is that expected?Yes, this brings us in alignment with BoringSSL which only permits P-256 and P-384
BoringSSL presumably added it for Google Cloud, https://boringssl-review.googlesource.com/c/boringssl/+/52625
The BoringCrypto fips-20210429 certificate approves P-521. SP 800-52r2 does not forbid P-521 either:
3.2 Server Keys and Certificates
If the server is configured with an ECDSA signature certificate, either curve P-256 or curve P-384 should be used for the public key in the certificate.12
12 The recommended elliptic curves now listed in FIPS 186-4 [45] will be moved to SP 800-186. Until SP 800-186 is published, the recommended elliptic curves should be taken from FIPS 186-4.
and
3.4.2.2 Supported Groups
When elliptic curve cipher suites are configured, at least one of the NIST-approved curves, P-256 (secp256r1) and P-384 (secp384r1), shall be supported as described in RFC 8422 [52]. Additional NIST-recommended elliptic curves are listed in SP 800-56A, Appendix D [6]. Finite field groups thatare approved for TLS in SP 800-56A, Appendix D may be supported.
Presumably this was the reason to enable it before in https://go-review.googlesource.com/c/go/+/343880
Is there a compelling reason to disable support for P-521? Normally it should not be in use, but there may be edge cases where support for such client/server certificates is still needed in TLS.
Comment From: gopherbot
Change https://go.dev/cl/558796 mentions this issue: Revert "crypto/internal/boring: upgrade module to fips-20220613" +1
Comment From: gopherbot
Change https://go.dev/cl/558797 mentions this issue: [release-branch.go1.22] Revert "crypto/internal/boring: upgrade module to fips-20220613" +1
Comment From: gopherbot
Change https://go.dev/cl/560275 mentions this issue: [release-branch.go1.21] Revert "crypto/internal/boring: upgrade module to fips-20220613" +1
Comment From: gopherbot
Change https://go.dev/cl/560276 mentions this issue: [release-branch.go1.20] Revert "crypto/internal/boring: upgrade module to fips-20220613" +1
Comment From: sAnjAy060897
@FiloSottile, I notice the boringcrypto version was downgraded back to fips-20210429 after go 1.21.6? I don't seem to find the reason for the same. We are planning to migrate to the latest FIPS 140-3 certified/in-review boring version for our products.
Can you please help us understand in which release the fips-20220613 be available? Is this version under review for FIPS 140-3 certification? Thanks!
Comment From: FiloSottile
@sAnjAy060897 see https://github.com/golang/go/issues/65321 linked above.
Comment From: gopherbot
Change https://go.dev/cl/603375 mentions this issue: crypto/internal/boring: upgrade module to fips-20220613 / certificate 4735
Comment From: gopherbot
Change https://go.dev/cl/603376 mentions this issue: crypto/tls: align FIPS-only mode with BoringSSL policy
Comment From: FiloSottile
We enabled TLS 1.3 when upgrading to the latest BoringCrypto module. That module's certificate does not include Ed25519, so we can't enable it as part of Go+BoringCrypto.
Note that we are now planning to deprecate Go+BoringCrypto in favor of pursuing a validation for a Go native module, see #69536.