| commit | f3230c304a6e77b78d43e52b3ab4da013272d318 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Sep 02 15:24:02 2025 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Sep 03 08:53:29 2025 -0700 |
| tree | aa3ae2ffd5861e1403e0eafcc0f63ba993f173d8 | |
| parent | 3682758ef1494a830615531b0e8f9cd02b4e4ad2 [diff] |
Test verifying signatures over "unusual" TBSCertificates Test that, signatures over unusual TBSCertificates are verified correctly. This tests that encoding is correctly round-tripped through the parser to the verifier. In principle, this should never happen because a DER parser will only accept the canonical encoding of an object. However, it is possible for encoding to not round-trip if we accept any BER inputs, or our in-memory representation does not capture the full range of abstract TBSCertificate values. X509 objects cache the encoded TBSCertificate, so all encoding variations should be captured. This test tries to exercise the cache's effects on signature verification. In reality, the cache is barely load-bearing. We now reject most non-DER inputs, and X509_NAME also saves its encoding. Still, the test ensures this remains the case. Amusingly, you're actually formally *not* supposed to do this. An X.509 signature is defined to use the DER encoding of the TBSCertificate. An ASN.1 type is independent of the particular encoding used. If you parsed a BER (or XER!) X.509 Certificate, you're meant to canonicalize the encoding back to DER to verify it. As far as I know, no one does it that way. Change-Id: I67c4932ec87d1f6fedfc8c711cf0f7837759947e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81768 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: 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:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: