Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: crypto/tls: allow configurability of supported Signature Hash Algorithms #28660
Go up to and including the current version (at this writing, 1.11.2) hardcodes the list of supported algorithms for the TLS 1.2 Signature Algorithms extension. Concurrently,
One real-world example of this is a custom signer for a TLS client that uses a hardware backend such as a Trusted Platform Module. TPM 1.2 modules can only support SHA1, and while TPM 2.0 modules can support SHA512, they are only required under the current spec to support SHA1 and SHA256. Depending on the list of algorithms provided by the remote party, the Go implementation may choose a 384-bit or 512-bit algorithm that is not supported by the backing hardware module, causing the handshake to fail.
In order to address this, I propose adding a configuration option to
This sounds like it would be more cleanly addressed by an interface upgrade on
Happy to consider this for Go 1.13. Go 1.12 is now in feature freeze.
While I understand the line of thinking, I'm not sure tying this directly to
In order to query the
Given these points, I believe it makes the most sense to define this selection in the
TLS 1.3, which requires RSA-PSS, is now enabled without a GODEBUG opt-out, and with the introduction of Certificate.SupportedSignatureAlgorithms (#28660) there is a programmatic way to avoid RSA-PSS (disable TLS 1.3 with MaxVersion and use that field to specify only PKCS#1 v1.5 SignatureSchemes). This effectively reverts 0b3a57b, although following CL 205061 all of the signing-side logic is conveniently centralized in signatureSchemesForCertificate. Fixes #32425 Change-Id: I7c9a8893bb5d518d86eae7db82612b9b2cd257d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/205063 Run-TryBot: Filippo Valsorda <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Katie Hockman <email@example.com> Reviewed-by: Adam Langley <firstname.lastname@example.org>