| commit | 9cbe737ec4697f5f6ac0c5d9f4ea814b7087d90a | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Jun 15 18:09:10 2021 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Jun 18 23:08:26 2021 +0000 |
| tree | b4a1f49dc5eb9c248780142a2b3ce4f14c0442be | |
| parent | 869bf9f3afc52d901efb9f838ddbb28e5fa63570 [diff] |
Validate ECH public names. This was added in draft-11, which I'll update to more broadly in a follow-up CL. This is an easily separable component: we don't want to allow the DNS to arbitrarily insert strings in the ClientHello, so invalid public names are rejected. Unfortunately, we have a bit of a mess because DNS syntax does not exclude IPv4 literals, yet everyone sticks DNS and IP literals in the same string. The RFC3986 rules are alright, but don't match reality. Reality is (probably?) the WHATWG rules, which are a mess. The load-bearing bit of the spec is that, at certificate verification, you should reject whatever strings your application refuses to represent as a DNS name. I'll have Chromium call into its URL parser. https://www.ietf.org/archive/id/draft-ietf-tls-esni-11.html#section-6.1.4.3-3 But there's still a bit at the validation step where clients "SHOULD" run the IPv4 parser. In case downstream logic forgets, I've gone ahead and implemented the WHATWG IPv4 parser. https://www.ietf.org/archive/id/draft-ietf-tls-esni-11.html#section-4-6.6.1 Bug: 275 Change-Id: I15aa1ac0391df9c3859c44b8a259296e1907b7d4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48085 Commit-Queue: David Benjamin <davidben@google.com> 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.
Project links:
There are other files in this directory which might be helpful: