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 <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>fips-20240407
parent
69eec38a25
commit
60c2867092
7 changed files with 79 additions and 6 deletions
Loading…
Reference in new issue