| commit | 68c29a24ee6c9c70ecce56766ca70b115aad768f | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue May 21 13:56:34 2024 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue May 21 19:16:55 2024 +0000 |
| tree | 4e636fb757e89fc8508db40a8fd7380d8b64a914 | |
| parent | de6ba216656b819d4d8de7602006561f82a8c669 [diff] |
Check DSA size limits in a couple more places This change was prompted by CVE-2024-4603, but is *not* part of it. BoringSSL is not affected by CVE-2024-4603. When applications use DSA they are expected to use known-valid domain parameters (as required by FIPS 186-4, section 4.3). If the application instead allows the attacker to supply domain parameters, DSA is no longer cryptographically sound, and algorithms that were otherwise correct now become DoS attack surfaces. Alas, incorrect uses of DSA, like Diffie-Hellman (see CVE-2023-3446 and CVE-2023-3817) are rampant, so it is useful to bound our operations, so we at least can say something coherent about DoS in this scenario, even though we cannot avoid the application being cryptographically unsound. To that end, we already check DSA sizes before using the key, however, we missed a couple of operations: - DSA_generate_parameters_ex - DSA_generate_key The CL adds those too. I would not expect either to have any security impact as it's quite unlikely for an application to allow attacker control of the inputs to either function. Still, we ought to check for completeness' sake. There's no sense in generating parameters or a key that we know we'll reject. Ultimately, the problem here is that DSA was a badly-designed primitive. with a continuum of domain parameters. Experience has shown that such systems are confusing and applications will often incorrectly treat domain parameters as part of the key. Modern primitives use a small set of discrete, named parameter sets, which is far easier to get right. For this reason, we consider DSA a deprecated, legacy algorithm. Change-Id: Ib3b5dece32bcb0ac9a795f8222c1c530d9dd91a0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68707 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: 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: