| commit | 3a1b7306ac18110024f1b716c2aa61f17732e02a | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Nov 29 18:44:46 2022 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Dec 02 19:45:36 2022 +0000 |
| tree | c32a83fd467d15a480d17ed4169858f0d6553206 | |
| parent | e8f57ca134ffd297e5c46505c86ff7001ef32f7b [diff] |
Don't allow the caller to configure invalid signature algorithms. It should not be possible to make BoringSSL request unknown signature algorithms, or the special SSL_SIGN_RSA_PKCS1_MD5_SHA1 value, in the ClientHello or CertificateRequest. Update-Note: This CL makes unknown values fail SSL_set_verify_algorithm_prefs, etc. SSL_SIGN_RSA_PKCS1_MD5_SHA1 is silently dropped from the list, rather than an error because, although documented as incorrect, this hole in the abstraction seems to be confusing. I think there's some code in Chromium which accidentally puts it in the signing prefs (wrong but harmless) and I often need to explain to folks that it doesn't belowing in verify prefs (puts it in the ClientHello). This makes us tolerate the value by ignoring it. This makes the previous pkey_supports_algorithm change moot because we'd never get that far with SSL_SIGN_RSA_PKCS1_MD5_SHA1, but I think the check, but I think the check belongs in that function too. The test also reveals that some of our tests have been accidentally passing zero into the preference list all this time. Change-Id: I76d4eb98682515c3b819e0ed8d44f2d708a98975 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55446 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: