| commit | efad2bfc83544bb926921de61baf6f962e685671 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Feb 23 14:37:10 2024 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Mar 05 18:03:24 2024 +0000 |
| tree | 27d6f28485ec0c04bb9eda798e2ebbc7464882dc | |
| parent | 9f376b0694dfb8528fa2200369b48632563e972f [diff] |
Fix delegated credential signature algorithm handling https://boringssl-review.googlesource.com/c/34884 tried to update to the newer DC draft, but didn't quite do so. In that update, DCs overcomplicated the signature algorithm negotiation so that there are two different signature algorithm lists, used in different contexts. The existing signature_algorithms extension is used to verify the signature *on* the DC, made by the end-entity certificate. On the server side, we should be using that to decide whether to use the DC, and we weren't. The new delegated_credentials extension contains another sigalg list. That is used to verify the signature *by* the DC, in the CertificateVerify message. (This means DC changes the operative sigalg list for the CertificateVerify message, which is quite a mess.) On the server side, the above CL mixed things up. When deciding whether to use DCs, it checked the correct list. When actually using DCs, it checked the wrong one. As a result, any time the DC list wasn't a subset of the main list, the connection would just break! Fix both of these, in preparation for redoing DCs over the upcoming SSL_CREDENTIAL mechanism. Thankfully we don't support one direction of DC usage (authenticating in C++ and verifying in Go), so there are fewer places to worry about mixing this up. Given this overcomplication, I'm now much, much less inclined to ever support DCs as a client, without an rfc9345bis to redo this. Bug: 249 Change-Id: Id5257e89a6c8daf1635757be473c45029492d420 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66550 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: