| commit | cee2dbb08cb3daf56995875207b5e947310697de | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Apr 14 16:47:59 2023 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Apr 17 18:16:47 2023 +0000 |
| tree | c10695ce6c6d69735ac37e89633f84128d2215a5 | |
| parent | fa7afff95a7e490afc50c8b554dbd24e8e30101c [diff] |
Default SSL_set_enforce_rsa_key_usage to enabled. This relands https://boringssl-review.googlesource.com/c/boringssl/+/54606, which was temporarily reverted. Update-Note: By default, clients will now require RSA server certificates used in TLS 1.2 and earlier to include the keyEncipherment or digitalSignature bit. keyEncipherment is required if using RSA key exchange. digitalSignature is required if using ECDHE_RSA key exchange. If unsure, TLS RSA server signatures should include both, but some deployments may wish to include only one if separating keys, or simply disabling RSA key exchange. The latter is useful to mitigate either the Bleichenbacher attack (from 1998, most recently resurfaced in 2017 as ROBOT), or to strengthen TLS 1.3 downgrade protections, which is particularly important for enterprise environments using client certificates (aka "mTLS") because, prior to TLS 1.3, the TLS client certificate flow was insufficiently encrypted or authenticated. Without reflecting an RSA key exchange disable into key usage, and then the client checking it, an attacker can spoof a CertificateRequest as coming from some server. This aligns with standard security requirements for using X.509 certificates, specified in RFC 5280, section 4.2.1.3, and reiterated in TLS as early as TLS 1.0, RFC 2246, section 7.4.2, published 24 years ago on January 1999. Constraints on usage of keys are important to mitigate cross-protocol attacks, a class of cryptographic attacks that is well-studied in the literature. We already checked this for each of ECDSA, TLS 1.3, and servers verifying client certificates, so this just fills in the remaining hole. As a result, this change is also important for avoiding some weird behaviors when configuration changes transition a server in or out of this hole. (We've seen connection failures get misattributed to TLS 1.3 when it was really a certificate misconfiguration.) Chrome has also enforced this for some time with publicly-trusted certificates. As a temporary measure for callers that need more time, the SSL_set_enforce_rsa_key_usage API, added to BoringSSL in January 2019, still exists where we need to turn this off. Fixed: 519 Change-Id: I91bf2cfb04c92aec7875e640f90ba6f837146dc1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58805 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: