commit | c67076d653f7501136f7b208df4b011a7275e8f5 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Tue Apr 16 17:39:50 2019 -0500 |
committer | Adam Langley <agl@google.com> | Mon Apr 22 21:32:29 2019 +0000 |
tree | b6938e801dca6d852006e9870314b0e296f79874 | |
parent | e55c64fdd3f47413e17eaa8e4f4d2a62622a01eb [diff] |
Require certificates under name constraints use SANs. The common name fallback does not interact well with name constraints. Until we remove this fallback, we must resolve this conflict. Blindly applying name constraints to the common name will reject "decorative" common names that aren't intended to be hostnames (e.g. [0]). We need to guess based on format whether the common name is a DNS name. It is important this same check is applied to *both* name constraints and name matching, which means the OpenSSL version (see 5bd5dcd49605ca2aa7931599894302a3ac4b0b04, d02d80b2e80adfdde49f76cf7c7af4e013f45005, and 55a6250f1e7336e8a7d89fb609eb23398715ff6f) is unsuitable as a compatibility data point. In theory we could limit this to chains with name constraints, which are uncommon, but X509_check_host sees only the leaf. We must apply it uniformly. That means a strict check risks problems with malformed non-WebPKI setups like [1]. For a first pass, mirror Go's behavior. Like Go, rather than run SAN-less DNS-like common names through name constraints, we simply reject all such certificates. Name constraints now exclude all leaf certificates that can trigger the common name fallback. They are rare enough that we can hopefully hold them to a higher standard. Note this does not make misclassified decorative common names any worse, compared to the checking the name constraint. Such names would not have matched the constraint anyway. Update-Note: This can may cause two kinds of errors: 1. Leaf certificates whose chain contains a name constraint and lack SANs may be rejected with X509_V_ERR_NAME_CONSTRAINTS_WITHOUT_SANS. 2. Leaf certificates which use the common name fallback and verify against an insufficiently DNS-looking hostname may fail with X509_V_ERR_HOSTNAME_MISMATCH. In both cases, the fix is to include the subjectAltName in the certificate, rather than rely on the common name fallback. (Refining the heuristic is also an option, but the two failure modes pull it in opposite directions, so this is tricky.) [0] https://github.com/golang/go/issues/24151 [1] https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/194 Change-Id: If25557de428768292a14ba3bdeeffbd74e3a3bf8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35665 Reviewed-by: Adam Langley <agl@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.
There are other files in this directory which might be helpful: