-
Notifications
You must be signed in to change notification settings - Fork 122
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Check client certificate types in TLS <= 1.2
TLS <= 1.2 servers indicate supported client certificate key types with a certificate_types field in the CertificateRequest. Historically, we've just ignored this field, because we've always outsourced certificate selection to the caller anyway. This meant that, if you configured an RSA client certificate in response to a server that requested only ECDSA certificates, we would happily send the certificate and leave it to the server to decide if it was happy. Strictly speaking, this was in violation of RFC 5246: - The end-entity certificate provided by the client MUST contain a key that is compatible with certificate_types. [...] Although prior TLS versions didn't say anything useful about this either way. Once we move certificate selection into the library, we'll want to start evaluating supported algorithms ourselves. A natural implementation of it will, as a side effect, cause us to enforce this match, even when only a single certificate is configured. Since this is unlikely to have any real compatibility impact (every TLS server I've seen just hardcodes this list), let's just try turning it on. On the off chance it does break someone, I've left a flag, SSL_set_check_client_certificate_type, for folks to turn this check off. The flag will most likely be unnecessary, in which case we can retire it after a few months. If this does cause a problem, we can opt to turn it off for the default certificate, or only enable it when multiple certificates are configured, or lean on the sigalgs list (doesn't work for 1.0/1.1), but these all result in some slightly suboptimal behavior, so I think we should treat them as contingency plans. Update-Note: A TLS 1.2 (or below) client, using client certificates, connecting to a TLS server which doesn't support its certificate type will now fail the connection slightly earlier, rather than sending the certificate and waiting for the server to reject it. The connection should fail either way, but now it will fail earlier with SSL_R_UNKNOWN_CERTIFICATE_TYPE. If the server was buggy and did not correctly advertise its own capabilities (very very unlikely), this may cause a connection to fail despite previously succeeding. We have included a temporary API, SSL_set_check_client_certificate_type, to disable this behavior in the unlikely event this has any impact, but please contact the BoringSSL team if you need it, as it will interfere with improvements down the line. This change does not affect servers requesting client certificates, only clients sending them. Bug: 249 Change-Id: I159bc444c4ee79fbe5c476d4253b48d58d2538be Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66687 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]> (cherry picked from commit 60c2867092af66bbe369f00d8214b6d06fcb376a)
- Loading branch information
Showing
7 changed files
with
79 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters