| commit | 9280f153df0e4c651d658fb1f137dfc18136144e | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Mar 01 17:20:04 2024 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Mar 06 18:19:57 2024 +0000 |
| tree | 8664c3c729a19907a766900439816bea2915779d | |
| parent | e202e51cb0912f36dafbd2e67cf04d6ec82f3180 [diff] |
Check ECDSA curves in TLS 1.2 servers In TLS 1.2 and below, the supported_curves list simultaneously contrains ECDH and ECDSA. Since BoringSSL, previously, did not handle ECDSA certificate selection in the library, we ignored the latter and left it to the callers. If configured with an ECDSA certificate that didn't match the peer's curve list, we proceeded anyway, and left it to the client to reject the connection. This contradicts RFC 8422, which says: The server constructs an appropriate certificate chain and conveys it to the client in the Certificate message. If the client has used a Supported Elliptic Curves Extension, the public key in the server's certificate MUST respect the client's choice of elliptic curves. A server that cannot satisfy this requirement MUST NOT choose an ECC cipher suite in its ServerHello message.) As with the previous client certificate change, once we move certificate selection into the library, we'll need to evaluate this 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. This CL lands that behavior change ahead of time and, in case there are compatibility impats, leaves a flag, SSL_set_check_ecdsa_curve, to restore the old behavior. If the change goes through fine, we can retire the flag 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, but these all result in some slightly suboptimal behavior, so I think we should treat them as contingency plans. To help debugging, I gave this a dedicated error, though doing so is a little tricky because of the PSK fallback. (See the CheckECDSACurve-PSK-TLS12 test.) Update-Note: A TLS 1.2 (or below) server, using an ECDSA certificate, connecting to a client which doesn't advertise its ECDSA curve will now fail the connection slightly earlier, rather than sending the certificate and waiting for the client to reject it. The connection should fail either way, but now it will fail earlier with SSL_R_WRONG_CURVE. If the client was buggy and did not correctly advertise its own capabilities, this may cause a connection to fail despite previously succeeding. We have included a temporary API, SSL_set_check_ecdsa_curve, to disable this behavior in the event this has any impact, but please contact the BoringSSL team if you need it, as it will interfere with improvements down the line. TLS 1.3 is not impacted by this change, neither are clients, or RSA certificiates. Additionally, if your server was already looking at the curve list before configuring an ECDSA certificate in TLS 1.2, this will also have no impact. Bug: 249 Change-Id: I2f1d4e2627641319556847cbbbcdddf347bbc8a9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66688 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: