| commit | 246c556b65c3235c8eb082c15017c9669815943a | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Thu May 20 13:42:25 2021 -0400 |
| committer | David Benjamin <davidben@google.com> | Wed Jun 09 22:32:16 2021 +0000 |
| tree | ba3c4bd413bd0fb65617e52d100dafaec57d75ef | |
| parent | 43ab56c618fc5212e36b9e20ad48549d3bbcc0ec [diff] |
Compute the ECH GREASE payload outside of the callbacks. This is kinda annoying and, like the grease_seed, demonstrates a shortcoming with the idea of making add_clienthello completely const. Strictly speaking, we only need idempotence. But I think this is okay: const is much easier to enforce than idempotence, and we'll likely need to do this anyway: - While not in the current draft, I expect the draft's eventual HRR resolution to retain the ECH extension, GREASE or not, on ECH reject. Things are somewhat violating RFC8446 HRR rules right now. That means we'll need to stash the ECH payload regardless. - ECH binds all the other extensions in the outer ClientHello, so computing the payload will need to move outside the callback system anyway. In some sense, all this is shifting our ClientHello output from the "immediate mode" end of the spectrum (as we usually use) to the "retained mode" end, which I suppose makes sense as this message becomes more intricate. Bug: 275 Change-Id: I9eb8cd1cde2ce264345b6ed3ee526d4eab81e911 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47990 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: