Handle an API edge case with PSKs and client certificates If a client is configured to accept PSKs or server certificates, the server may authenticate with a certificate and then request a client certificate. The client may then wish to decline to send a client certificate. We normally express this with an empty credential list. But such a client cannot have an empty credential list because it contains PSKs. Due to the order of protocol decisions, the client's credential list is effectively two credential lists: a set of "non-certificate" credentials (PSKs, PAKEs), which can pick non-certificate modes, and then a set of "certificate" credentials. We only care if the second one is empty. In other words, skip over PSK/PAKE credentials when evaluating emptiness. They're still one combined list because, on the server, the choice is made at the same time and having one combined list is helpful to express an ordering. (For this purpose, a raw public key is a certificate credential.) Bug: 369963041 Change-Id: If7b06e2bd347a187499a8621eb692c4a87c5dbf6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/89567 Reviewed-by: Lily Chen <chlily@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:
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: