crypto/tls: FIPS 140-3 modes reject ECDSA w/ curve P-521/SHA-512 in TLS

[sgmiller]

Go version

go version go1.24.0 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/scott/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/scott/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build240290176=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/scott/go/pkg/mod'
GOOS='linux'
GOPATH='/home/scott/go'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/scott/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.0.linux-amd64'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/scott/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/scott/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.0.linux-amd64/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.0'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

In updating our software to 1.24, using FIPS mode (in our case BoringCrypto in order to be against a CMVP validated module), TLS broke in our cluster communication. We generate ECDSA P-521 keys for our certificates, which according to our read of Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program, and SP 800-186 is an allowed curve when paired with SHA-512 (ECDSAWithP521AndSHA512). These are rejected by Go 1.24, due to this list of allowed ciphers in crypto/tls/defaults.go:

// defaultSupportedSignatureAlgorithmsFIPS currently are a subset of
// defaultSupportedSignatureAlgorithms without Ed25519 and SHA-1.
var defaultSupportedSignatureAlgorithmsFIPS = []SignatureScheme{
	PSSWithSHA256,
	PSSWithSHA384,
	PSSWithSHA512,
	PKCS1WithSHA256,
	ECDSAWithP256AndSHA256,
	PKCS1WithSHA384,
	ECDSAWithP384AndSHA384,
	PKCS1WithSHA512,
}

This list over prunes defaultSupportedSignatureAlgorithms, losing the last non-SHA-1 line, or possibly P-521 wasn't allowed in FIPS 140-2 but is in -3. In addition, Ed25519 should probably also be supported in FIPS 140-3 (not -2 of course).

What did you see happen?

"error handshaking cluster connection: error="tls: peer doesn't support any of the certificate's signature algorithms"

What did you expect to see?

A successfully negotiated TLS connection.

[sgmiller]

Looks like prior to 1.24, when the defaults were not broken out, the algorithm was present: 0b57881

[seankhliao]

cc @golang/security

[sgmiller]

Ah, I see this was done on purpose: d363534. Will try to dig up the rationale, but this is a breaking change for our HC Vault clustering code.

[gabyhelp]

Related Issues

• crypto/tls: Permit recently FIPS-approved protocols/algorithms #62372 (closed)
• crypto/tls: TLS 1.2 SupportedSignatureAlgorithms not honored in Server Hello Certificate Request #40344 (closed)
• dev.boringcrypto: AES_128_CBC_SHA and AES_256_CBC_SHA missing in defaultFIPSCipherSuites #36647 (closed)
• boringcrypto: SHA functions do not use FIPS compliant openssl APIs #66520 (closed)
• crypto/ecdsa: custom curve implementations are not supported with boringcrypto #54486 (closed)
• dev.boringcrypto: Unable to connect to a server using the `tls.TLS_RSA_WITH_AES_256_CBC_SHA` CipherSuite #44050
• crypto/tls: remote error: tls: handshake failure #46270 (closed)
• crypto/x509: Incorrect RSA key size limitations in BoringCrypto/FIPS 140-2 mode #53755 (closed)

Related Code Changes

• [dev.boringcrypto] crypto/tls: permit P-521 in FIPS mode

Related Discussions

• boringcrypto+fipsonly: way more strict than fips 140-2?

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[cipherboy]

@FiloSottile @rolandshoemaker I'm confused by this.

I don't see how BoringSSL rev 20220613 / cert 4735 (used per Dockerfile) forbids P-521/SHA-512 since ECDSA FIPS 186-4 with P-521 is permitted under A2811 (page 8 & 9) unless the specific hash combination wasn't tested or it wasn't validated by the lab for TLS use? Perhaps it has to do with Page 18/19's ECDSA Signing Key bits field? The BoringSSL ACVP wrapper code at the FIPS tag seem to test it: https://github.com/google/boringssl/blob/fips-20220613/util/fipstools/acvp/modulewrapper/modulewrapper.cc#L448-L513. Likewise the ECDSASigVer uses HashFromName which supports SHA2-512, so as long as the ACVP server gave it to the module, it should be tested and certified AFAICT. (That is, assuming the ACVP testing was done using the utility at that tag.)

Related, but why is HKDF not present/certified? I see nothing in that module's policy allowing the use of TLSv1.3; only 1.2 and earlier KDFs. It is likewise missing from the ACVP. Documents like OpenSSL Foundation's certification, BouncyCastle's v2.1.0 certificate, and Red Hat's OpenSSL certificate all clearly permit TLSv1.3 and have certified HKDF for use. The BoringSSL code at the fips-20220613 tag (linked above) doesn't seem to have enabled HKDF support. On main it has.

Honestly, it seems like this patch is reversed. We should disable TLSv1.3 and enable P-521?

---

It seems like the discussion linked here and in #62372 (comment) are referring to a different version of the SP than what was certified by NIST...?

[sgmiller]

Re-edited the issue title, as this is not a boringcrypto specific problem, the code that restricts the TLS signature modes is not specific to any particular FIPS 140-3 mode of Go 1.24.

[FiloSottile]

The Go+BoringCrypto choices are based on BoringSSL's ssl_compliance_policy_fips_202205 and we are generally not going to diverge from the BoringSSL behavior in that mode because we don't own the BoringCrypto module and don't have full visibility into its choices. (This was one of the motivations for the Go native module.)

As for the Go FIPS 140-3 mode, NIST SP 800-52r2 Sections 3.2, 3.4.2.2, and 4.4.2.2 give a SHOULD for P-256 / P-384 on certificates (and a SHALL support P-256 / P-384 for key exchange with the option of using others). SP 800-52 is a more restrictive profile that applies to certain federal entities, so there is a valid argument for relaxing it.

[cipherboy]

@FiloSottile Thanks!

BoringSSL's ssl_compliance_policy_fips_202205

As far as I can tell, this policy was added after certification and is not present on the fips-20220613 tag. It doesn't necessarily comply with the certified artifacts given HKDF was not certified and thus TLSv1.3 is a non-approved mode of operation, despite being allowed by SP800-52r2.

Has the suggestion to use this mode (and its compliance with the actual certificate) been given elsewhere? As far as I can tell based on the initial comment here, that was the only other mention of this policy. AFAICT as an outsider, it looks like future work for a new certification.

---

Since Go is also not using the BoringSSL TLS stack but instead reusing Go's native TLS stack from certified primitives, I think relaxing 800-52r2 compliance would be at this project's discretion.

As noted in #62372 though, at the time of SP800-52r2's publication, P-521 was a NIST-approved curve, though I will admit it is curious it wasn't called out in 3.4.2.2 Supported Groups. Sadly I can't seem to load any of the draft comments, even from the Wayback archive. But I agree with your interpretation here:

with the option of using others

So P-521 should be allowed within that scope, even if not the highest priority item; nothing in Sp800-52r2 precludes the use of other NIST/FIPS approved curves.

---

That is, more concretely, I suppose the answer is it is hard to write a general policy that describes what approved modules actually certify versus what is theoretically approved. I'd probably suggest a FIPS profile selector which allows everything theoretically allowed versus strict internal compliance... and then allow the underlying module to expose certified primitives and compute the actual policies. My 2c.

[gopherbot]

Change https://go.dev/cl/650576 mentions this issue: crypto/tls: relax native FIPS 140-3 mode

[FiloSottile]

Go+BoringCrypto has always been an unsupported mode primarily tracking the internal requirements of Google. We are not going to diverge from BoringSSL's choices there.

However, the point of doing our own native validation is being able to make reasoned choices for Go, and I agree we can relax the policy when using our module. We can even include Ed25519 and the ML-KEM hybrid! I mailed CL 650576.

Kind of on the fence on whether we should backport it. @rolandshoemaker and @cpu?

That is, more concretely, I suppose the answer is it is hard to write a general policy that describes what approved modules actually certify versus what is theoretically approved. I'd probably suggest a FIPS profile selector which allows everything theoretically allowed versus strict internal compliance... and then allow the underlying module to expose certified primitives and compute the actual policies. My 2c.

Another upside of having our own tightly coupled module is that we don't need to do complex computations between crypto/tls and the module: we know what module we ship and what it certifies, so we can just make that the FIPS 140-3 mode policy.