| commit | 28226f584e8fb65eb8730721dcb5001f2a072efc | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed Mar 29 14:04:44 2023 +0900 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Mar 30 04:56:45 2023 +0000 |
| tree | 24e1184a1fd67e6c909262fa5c5ff53babd53b0c | |
| parent | fca688f26b939db9c9981204373cecbd108b5d6c [diff] |
Fix handling of critical X.509 policy constraints If we see a critical policy constraints extension, we have two options: We can either process it, which requires running policy validation, or reject the certificate. We and OpenSSL do neither by default, which means we may accept certificate chains that we weren't supposed to. This fixes it by enabling X.509 policy validation unconditionally and makes X509_V_FLAG_POLICY_CHECK moot. As a side effect, callers no longer need to do anything for CVE-2023-0466. This is the opposite of [0]'s advice, which instead recommends skipping the feature and rejecting critical policy contraints. That would be a good move for a new X.509 implementation. Policy validation is badly-designed, even by X.509's standards. But we have OpenSSL's history of previously accepting critical policy constraints (even though it didn't check it). I also found at least one caller that tests a chain with policy constraints, albeit a non-critical one. We now have an efficient policy validation implementation, so just enable it. Of course, fixing this bug in either direction has compatibility risks: either we take on the compat risk of being newly incompatible with policyConstraints-using PKIs, or we take on the compat risk of newly rejecting certificates that were invalid due to a policy validation error, but no one noticed. The latter case seems safer because the chain is unambiguously invalid. Update-Note: X.509 certificate verification (not parsing) will now notice policy-validation-related errors in the certificate chain. These include syntax errors in policy-related extensions, and chains with a requireExplicitPolicy policy constraint that are valid for no certificate policies. Such chains are unambiguously invalid. We just did not check it before by default. This is an obscure corner of X.509 and not expected to come up in most PKIs. [0] https://www.ietf.org/archive/id/draft-davidben-x509-policy-graph-01.html#section-3.4.4 Fixed: 557 Change-Id: Icc00c7797bb95fd3b14570eb068543fd83cda7b9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58426 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@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: