Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: crypto/tls: allow configurability of supported Signature Hash Algorithms #28660

Open
e3b0c442 opened this Issue Nov 8, 2018 · 2 comments

Comments

Projects
None yet
4 participants
@e3b0c442
Copy link

e3b0c442 commented Nov 8, 2018

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, crypto/tls also allows the use of custom signers which may have their own limitations not addressed by the hardcoded list of supported algorithms.

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 tls.Config to allow a custom list of supported signature algorithms to be provided, which will allow custom signer implementations to express the algorithms they support.

@bradfitz bradfitz changed the title crypto/tls: allow configurability of supported Signature Hash Algorithms proposal: crypto/tls: allow configurability of supported Signature Hash Algorithms Nov 8, 2018

@gopherbot gopherbot added this to the Proposal milestone Nov 8, 2018

@gopherbot gopherbot added the Proposal label Nov 8, 2018

@FiloSottile

This comment has been minimized.

Copy link
Member

FiloSottile commented Nov 8, 2018

This sounds like it would be more cleanly addressed by an interface upgrade on crypto.Signer allowing it to communicate which ones it supports, than by yet another tls.Config switch. Moreover, this is a property of the selected certificate, not of the system as a whole (forcing the use of GetConfigForClient.

Happy to consider this for Go 1.13. Go 1.12 is now in feature freeze.

@e3b0c442

This comment has been minimized.

Copy link
Author

e3b0c442 commented Nov 9, 2018

While I understand the line of thinking, I'm not sure tying this directly to crypto.Signer is the best option.

In order to query the crypto.Signer, there would need to exist some set of values to define the algorithms the crypto.Signer supports. While such a list exists in crypto/tls, I see two problems co-opting that for the crypto.Signer:

  1. crypto.Signer is more generalized and can be used in contexts not related to TLS, so one would not want crypto.Signer to refer to crypto/tls for a list of allowable values.

  2. Given that crypto.Signer can be an arbitrary implementation, I'm not sure it is possible or advisable to try to enumerate the parameters needed for the TLS implementation to determine a list of supported algorithms.

Given these points, I believe it makes the most sense to define this selection in the crypto/tls package somehow. That said, there is another option that satisfies keeping the selection in crypto/tls while not further complicating tls.Config: adding the field to tls.Certificate. This ties the algorithm selection to the crypto.Signer while not encumbering crypto.Signer with TLS knowledge, while at the same not adding additional fields to tls.Config and recognizing that the limitations are with the private key signer and not with the client itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.