Proposal Details
Currently, the Go cryptography modules do not enforce strict FIPS 140 compliance when FIPS mode is enabled. This is generally beneficial, as strict enforcement can lead to application incompatibility. For users who require strict compliance, the fips140=only GODEBUG setting is available. Additionally, issue #74630 suggests that more granular control may be supported in the future.
However, this flexible approach is not consistently applied across the standard library. Specifically, the crypto/tls package enforces strict FIPS 140 compliance when the fips140=on GODEBUG is set, limiting TLS versions, cipher suites, curves, and signature algorithms to only those that are FIPS-approved.
I have received feedback from users expressing concerns about this strict behavior. The current all-or-nothing enforcement model negatively impacts interoperability in certain environments.
I suggest updating crypto/tls to follow the same approach as other cryptographic packages: allow all algorithms and configurations by default, even when GODEBUG=fips140=on is set. This proposal pertains only to the blocking of algorithms and configurations—not their prioritization. It may still be appropriate to prefer FIPS-compliant options when FIPS mode is enabled.
I'm unsure whether this change would be considered a breaking change under the Go compatibility policy. If so, an alternative could be to introduce a new GODEBUG setting to preserve the current behavior for users who depend on it.
@golang/security
Comment From: gabyhelp
Related Issues
- crypto/fips140: selective policy enforcement framework #74630
- crypto: mechanism to enable FIPS mode #70123 (closed)
- crypto: no documentation for GODEBUG=fips140 #71666 (closed)
- crypto: FIPS Mode and Validation of Crypto Provider? #11658 (closed)
- cmd/go: add fips140 module selection mechanism #70200 (closed)
- crypto/tls: Permit recently FIPS-approved protocols/algorithms #62372 (closed)
Related Code Changes
Related Documentation
- The FIPS 140-3 Go Cryptographic Module > A native developer experience
- FIPS 140-3 Compliance > FIPS 140-3 mode
- Go 1.24 Release Notes > Standard library > FIPS 140-3 compliance
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: apparentlymart
Interesting! I've not yet had a chance to use the fips140=on mode in practice so I don't have a strong sense of what interop problems you're describing, but concerns about such problems are why I'd planned to set aside some time to understand better what exactly that setting does before using it. 😀
Given that I haven't used this in practice yet, the following may be a silly question. I'm sorry if so.
If the goal were only to prefer the FIPS-compliant algorithms, rather than to refuse to negotiate anything else, would it work to make the default behavior (when fips140=off) use that changed prioritization? Or would preferring the FIPS-compliant algorithms cause typical negotiation to result in selecting worse algorithms for those who don't care about compliance?
(A variation of what I just said might be to add a new fips140=preferred mode which adjusts the prioritization without disabling anything, leaving ips140=off completely unconstrained by FIPS compliance, while not breaking the expectations of anyone who already started relying on fips140=on. But I'm starting with "what if we just do this by default?" in the hope that it can avoid adding yet another variation while also not weakening the "on" mode that's already present. 🤔 )